Remove Dependency

[German]

Hi, i have pushed a change, having another change in the gerrit, both
without approval.. the second one depends on the first one. Now I
abandon the first one, and i cant approve the second one, how can I
remove the dependency link between them?...
I've been looking arround an searching in google, but i can't find the
way to do that.

thanks

[Jean-Baptiste Queru]

My typical workflow for this:

-repo start a new branch
-git cherry-pick
-repo upload --replace

JBQ

--
Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, Google.

Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.

[German]

But, there should be another way to do this.. right now i need to
clean up my branch...

On Sep 21, 12:34 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> My typical workflow for this:
>
> -repo start a new branch
> -git cherry-pick
> -repo upload --replace
>
> JBQ
>

[Jean-Baptiste Queru]

You can also do an interactive rebase of your branch and skip the
change you don't want any more.

JBQ

[German]

Or another question.. What is the workflow for a rejection?..

On Sep 21, 12:34 pm, Jean-Baptiste Queru <j...@android.com> wrote:

> My typical workflow for this:
>
> -repo start a new branch
> -git cherry-pick
> -repo upload --replace
>
> JBQ
>

[Jean-Baptiste Queru]

If the change is at the top of your branch:

-make local changes, git add, etc...
-git commit --amend
-repo upload --replace

(if it's in the middle of your branch, I think that an interactive
rebase with an "edit" for the change in question would do the trick).

JBQ

[German]

The thing is that, i'm not using repo, that is the only way to do
this?..

[Shawn Pearce]

On Mon, Sep 21, 2009 at 09:28, German <german...@gmail.com> wrote:
>
> The thing is that, i'm not using repo, that is the only way to do
> this?..

See the docs: http://gerrit.googlecode.com/svn/documentation/2.0/user-upload.html#push_replace

[Jean-Baptiste Queru]

you can replace the repo upload by an appropriate git push:

git push <project URL> <your local sha>:refs/changes/<gerrit change number>

JBQ

[Pavan Savoy]

A question based on this.
Suppose there are 2 changes, change-A and change-B, change-B is
dependent on change-A and if I upload a new patch set for change-A,
which isn't pulling change-B reflecting the 2nd patch set ?

that means, only pulling change-B, I always get the patch set-1 of
change-A and not patch-set 2 - why ?
How do I resolve this ?

regards,
Pavan

> >> >> > remove thedependencylink between them?...

[Shawn Pearce]

Pavan Savoy <pavan...@gmail.com> wrote:
> A question based on this.
> Suppose there are 2 changes, change-A and change-B, change-B is
> dependent on change-A and if I upload a new patch set for change-A,
> which isn't pulling change-B reflecting the 2nd patch set ?

Because the commit for the patch set on change-B points to the 1st
patch set on change-A.

In cases like this, when you upload a new change-A, you also must
upload a new change-B. Gerrit can't update change-B for you,
there might be merge conflicts that need to be resolved.

Using a push to refs/changes/<changenumber> like JBQ suggested
below is fine when there are no dependencies. With two commits,
you almost can handle it:

git push <URL> <commit-A>:refs/changes/A <commit-B>:refs/changes/B

but after that it gets impossible to do by hand. That's why
we introduced the Change-Id footer, and the commit-msg hook to
automatically insert it into commits for you.

> --
> To unsubscribe, email repo-discuss...@googlegroups.com
> More info at http://groups.google.com/group/repo-discuss?hl=en

[pavan savoy]

Yes,

This is exactly what I tried to do.
git push ... refs/changes/change-A = which got me patch set 2
but when I tried to do a
git push .. refs/changes/change-B = to get a patch set 2 dependent on
change-A (patch set2)

I get a squash commits first error..

regards,
Pavan

--
--Pavan Savoy

[Shawn Pearce]

pavan savoy <pavan...@gmail.com> wrote:
>
> This is exactly what I tried to do.
> git push ... refs/changes/change-A = which got me patch set 2
> but when I tried to do a
> git push .. refs/changes/change-B = to get a patch set 2 dependent on
> change-A (patch set2)
>
> I get a squash commits first error..

You must have created a 3rd commit and uploaded it as a replacement
to change-B. That's not what you wanted to do.

During the first upload, when changes A and B were first created
in Gerrit's database, your local Git repository should have looked
like this:

origin/master my-topic
| |
o--------------o-----------o

Gerrit assigned the changes and patch sets:

origin/master my-topic
| |
o--------------o-----------o
| |
A.1 B.1

Now you should have modified A using `git rebase -i HEAD~2`,
which creates the following:

origin/master
|
o--------------o-----------o
\ | |
\ A.1 B.1
\
\ my-topic
\ |
+--------o-----------o

You wanted to upload those two new commits to A and B, so Gerrit
can assign them as A patch set 2, B patch set 2:

origin/master
|
o--------------o-----------o
\ | |
\ A.1 B.1
\
\ my-topic
\ |
+--------o-----------o
| |
A.2 B.2

But, since you got a squash commits first error, it sounds like
perhaps you would up with this graph instead:

origin/master topic-B
| |
o--------------o-----------o-------o
\ | | /
\ A.1 B.1 /
\ /
\ topic-A /
\ | /
+--------o-------------+
|
A.2

Which is wrong, because A.1 and B.1 are both part of the history of
topic-B, which is what you tried to make Gerrt call A.2. If this
was actually submitted to your project, your bad versions of A
would actually be part of the project, polluting the history.

You should rebuild the branch that your "B" change is being developed
on by cherry-picking B.1 on top of A.2, getting you back to a graph
that looks like the 2nd one above. Then you should be ready to
upload it as a replacement for change B.

[pavan savoy]

>> > In cases like this, when you upload a new change-A, you also must
>> > upload a new change-B. Gerrit can't update change-B for you,
>> > there might be merge conflicts that need to be resolved.

Is there a hack or something in gerrit where we can remove off a
dependency for a particular changes, I makes sense when there are
merge conflicts for gerrit to have dependency.

But even when the change is totally independecy, still a git push
would result in a dependency for a particular change, why is that ?

regards,
Pavan

[Shawn Pearce]

pavan savoy <pavan...@gmail.com> wrote:
> >> > In cases like this, when you upload a new change-A, you also must
> >> > upload a new change-B. Gerrit can't update change-B for you,
> >> > there might be merge conflicts that need to be resolved.
>
> Is there a hack or something in gerrit where we can remove off a
> dependency for a particular changes, I makes sense when there are
> merge conflicts for gerrit to have dependency.

No. There isn't. Changing the dependency requires cherry picking
the commit onto a different base. That could cause a conflict, or
it might cherry-pick clean but the code might not work as expected.
So you have to do the cherry-pick (or rebase) locally so you have
a chance to test it before uploading a replacement commit that uses
a different base.

> But even when the change is totally independecy, still a git push
> would result in a dependency for a particular change, why is that ?

Because the commit you are pushing still has a parent that it was
based on. It didn't come out of nowhere, it was created by taking
some existing version of the project and changing things.

The only way to have no dependency is to create a branch new git
repository, add files to it, and make the first commit. But that
is no way to develop a project, because you are forced to start
over from scratch every time you make a change.

[Shawn Pearce]

On Tue, Nov 13, 2012 at 12:35 PM, ranjith ka <ranjith...@gmail.com> wrote:
> Depends-on: <blank>
> will remove the dependency

This is some sort of magic that is private to your environment. It has
nothing to do with Gerrit Code Review.

You need to rebase your change in Git so the parent is a different
commit, then push again to Gerrit.