[jitsi-dev] [libjitsi-commits] master: Merge branch 'deviceVolume' (c69cd21)


#1

Hey Vincent

I think "git merge feature-branch --no-ff" is great, but if the
feature-branch consists of only one commit, it seems a bit overkill. Would
you mind rebasing feature-branches onto the newest master and merging them
with --no-ff selectively? :slight_smile:

If others disagree, please say so, so that we can agree on a common pattern.

Ingo

From: commits-bounces@jitsi.org [mailto:commits-bounces@jitsi.org] On

Behalf

Of vincent.lucas@gmail.com
Sent: Mittwoch, 12. Juni 2013 20:35
To: commits@jitsi.org
Subject: [libjitsi-commits] master: Merge branch 'deviceVolume' (c69cd21)
Repository : ssh://lists.jitsi.org/libjitsi

On branch : master Link :
https://github.com/jitsi/libjitsi/compare/5f2398c37a26fb728c72a8651c26ef5
e8ea 1504b...c69cd21ed5ca5871a9fa7df3f46bcba943b21197

聽聽聽聽Merge branch 'deviceVolume'

wrote on ../jitsi/impl/neomedia/HardwareVolumeControl.java | 9

++++++++-:

路路路

-----Original Message-----
wrote on erge: 5f2398c 8b220cf:
_______________________________________________
commits mailing list
commits@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/commits


#2

Could you please explain what the difference is between the two options?

路路路

On Wed, Jun 12, 2013 at 10:00 PM, Ingo Bauersachs <ingo@jitsi.org> wrote:

Hey Vincent

I think "git merge feature-branch --no-ff" is great, but if the
feature-branch consists of only one commit, it seems a bit overkill. Would
you mind rebasing feature-branches onto the newest master and merging them
with --no-ff selectively? :slight_smile:

If others disagree, please say so, so that we can agree on a common pattern.

Ingo

-----Original Message-----
From: commits-bounces@jitsi.org [mailto:commits-bounces@jitsi.org] On

Behalf

Of vincent.lucas@gmail.com
Sent: Mittwoch, 12. Juni 2013 20:35
To: commits@jitsi.org
Subject: [libjitsi-commits] master: Merge branch 'deviceVolume' (c69cd21)
Repository : ssh://lists.jitsi.org/libjitsi

On branch : master Link :
https://github.com/jitsi/libjitsi/compare/5f2398c37a26fb728c72a8651c26ef5
e8ea 1504b...c69cd21ed5ca5871a9fa7df3f46bcba943b21197

wrote on erge: 5f2398c 8b220cf:
聽聽聽聽Merge branch 'deviceVolume'

wrote on ../jitsi/impl/neomedia/HardwareVolumeControl.java | 9

++++++++-:

_______________________________________________
commits mailing list
commits@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/commits

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
Emil Ivov, Ph.D. 67000 Strasbourg,
Project Lead France
Jitsi
emcho@jitsi.org PHONE: +33.1.77.62.43.30
http://jitsi.org FAX: +33.1.77.62.47.31


#3

Could you please explain what the difference is between the two options?

"ff" stands for fast-forward. Vincent's last few commits were like this:

A---B---C---D master
\----F----/ feature-branch

A is the parent of the feature-commit, F the feature commit and D the merge
commit of F. So one little fix ends up in two commits. This is not bad at
all, just a bit overkill for one commit.

For structures like

A---B---C-------------D master
\---F---G---H---I---/ feature-branch

it makes sense to go this way to keep track which commits (F,G,H,I) belonged
to a particular fix (D). However both samples above only work if git can
apply the "recursive" merge strategy, i.e. if there were no conflicts during
the merge. If there were conflicts, it would result in the discussion we had
about a month back.

Now the idea of rebasing would be to start from:
A---B---C master
\----F feature-branch

Rebase (on feature-branch, execute "git rebase master"):
A---B---C master
聽聽聽聽聽聽聽聽聽\---F feature-branch

Merge (with ff):
A---B---C---F master

Merge (with --no--ff):
A---B---C---------D master
聽聽聽聽聽聽聽聽聽\---F---/ feature-branch

Ingo


#4

Hello Ingo,

Thank you for the explanation. I will try to remember it for future commits.

Regards,
Vincent

路路路

On 6/12/13 10:22 PM, Ingo Bauersachs wrote:

Could you please explain what the difference is between the two options?

"ff" stands for fast-forward. Vincent's last few commits were like this:

A---B---C---D master
聽聽\----F----/ feature-branch

A is the parent of the feature-commit, F the feature commit and D the merge
commit of F. So one little fix ends up in two commits. This is not bad at
all, just a bit overkill for one commit.

For structures like

A---B---C-------------D master
聽聽\---F---G---H---I---/ feature-branch

it makes sense to go this way to keep track which commits (F,G,H,I) belonged
to a particular fix (D). However both samples above only work if git can
apply the "recursive" merge strategy, i.e. if there were no conflicts during
the merge. If there were conflicts, it would result in the discussion we had
about a month back.

Now the idea of rebasing would be to start from:
A---B---C master
聽聽\----F feature-branch

Rebase (on feature-branch, execute "git rebase master"):
A---B---C master
聽聽聽聽聽聽聽聽聽聽\---F feature-branch

Merge (with ff):
A---B---C---F master

Merge (with --no--ff):
A---B---C---------D master
聽聽聽聽聽聽聽聽聽聽\---F---/ feature-branch

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev

--
Vincent Lucas, Ph.D. Jitsi developer
chenzo@jitsi.org http://jitsi.org


#5

Thank you very much for the explanation!

This does make sense as a general tip and a best practice. However I
wouldn't like us to have a strict rule one way or the other and reprimand
people when they fail to follow. Git is already making our lives
complicated enough as it is.

--sent from my mobile

路路路

On Jun 12, 2013 10:22 PM, "Ingo Bauersachs" <ingo@jitsi.org> wrote:

> Could you please explain what the difference is between the two options?

"ff" stands for fast-forward. Vincent's last few commits were like this:

A---B---C---D master
\----F----/ feature-branch

A is the parent of the feature-commit, F the feature commit and D the merge
commit of F. So one little fix ends up in two commits. This is not bad at
all, just a bit overkill for one commit.

For structures like

A---B---C-------------D master
\---F---G---H---I---/ feature-branch

it makes sense to go this way to keep track which commits (F,G,H,I)
belonged
to a particular fix (D). However both samples above only work if git can
apply the "recursive" merge strategy, i.e. if there were no conflicts
during
the merge. If there were conflicts, it would result in the discussion we
had
about a month back.

Now the idea of rebasing would be to start from:
A---B---C master
\----F feature-branch

Rebase (on feature-branch, execute "git rebase master"):
A---B---C master
聽聽聽聽聽聽聽聽聽\---F feature-branch

Merge (with ff):
A---B---C---F master

Merge (with --no--ff):
A---B---C---------D master
聽聽聽聽聽聽聽聽聽\---F---/ feature-branch

Ingo

_______________________________________________
dev mailing list
dev@jitsi.org
Unsubscribe instructions and other list options:
http://lists.jitsi.org/mailman/listinfo/dev