* Re: [PATCH RFC] rebase: add --revisions flag
From: Björn Steinbrink @ 2009-12-08 19:11 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git, Junio C Hamano
In-Reply-To: <20091208164449.GA32204@redhat.com>
On 2009.12.08 18:44:49 +0200, Michael S. Tsirkin wrote:
> On Tue, Dec 08, 2009 at 05:37:37PM +0100, Björn Steinbrink wrote:
> > On 2009.12.08 18:14:07 +0200, Michael S. Tsirkin wrote:
> > > On Tue, Dec 08, 2009 at 05:08:22PM +0100, Björn Steinbrink wrote:
> > > > On 2009.12.08 16:47:42 +0200, Michael S. Tsirkin wrote:
> > > > > Add --revisions flag to rebase, so that it can be used
> > > > > to apply an arbitrary range of commits on top
> > > > > of a current branch.
> > > > >
> > > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > > > ---
> > > > >
> > > > > I've been wishing for this functionality for a while now,
> > > > > so here goes. This isn't yet properly documented and I didn't
> > > > > write a test, but the patch seems to work fine for me.
> > > > > Any early flames/feedback?
> > > >
> > > > This pretty much reverses what rebase normally does. Instead of "rebase
> > > > this onto that" it's "'rebase' that onto this". And instead of updating
> > > > the branch head that got rebased, the, uhm, "upstream" gets updated.
> > >
> > > The last sentence is wrong I think - it is still the branch head that
> > > is updated.
> >
> > But you don't rebase the branch head. Before the rebase, the branch head
> > doesn't reference the commits that get rebased. For example:
> >
> > git checkout bar
> > git rebase --revisions foo bar
> >
> > You "rebase" the commits in foo's history, but you update bar.
>
> Yes, that's the who point of the patch.
Yes, and it's "backwards" compared to the existing "rebase" modes, but
more like "cherry-pick".
> The above applies a single commit, foo, on top of current branch bar.
Hm, no. I expected it to turn all commits reachable from foo into
patches and applying them to bar. But actually, that should hit the
special <since> mode of format-patch. So
git rebase --revisions foo bar
is (with your patch) actually the same as
git rebase foo bar
So actually the example should have been:
git rebase --root --revisions foo bar
Both invocations probably mess up the diff-stat as that becomes:
git diff --stat --summary foo
So it creates a diffstat of the diff from the working tree to "foo",
which can't be right.
>
> > WRT the result, the above command should be equivalent to:
> > git checkout bar
> > git reset --hard foo
> > git rebase --root --onto ORIG_HEAD;
> >
> > And here, the commits currently reachable through "bar" are rebased, and
> > "bar" also gets updated.
>
> So this
> 1. won't be very useful, as you show it is easy
> to achieve with existing commands.
One can "almost" achieve it.
git rebase --revision A..B foo
is about the same as:
git checkout foo
git reset --hard B
git rebase --onto ORIG_HEAD A
But:
a) The "reset --hard" obviously lacks the safety checks for clean
index/working tree.
b) "git rebase --abort" won't take you back to your initial state, but
to B.
c) It's not really obvious that you can do it and how to do it.
Another possibility would be:
git checkout B^0 # detach HEAD at B
git rebase foo # rebase onto foo
git checkout foo
git merge HEAD@{1} # Fast-forwards foo to the rebased stuff
That fixes a), avoid b) [because you don't mess up any branch head
early] but is still subject to c).
And for both methods, the ORIG_HEAD and HEAD@{1} arguments are somewhat
"unstable", e.g. checking out the wrong branch head first, and only then
the correct one, you'd have to use HEAD@{2} instead of HEAD@{1} (because
the reflog for HEAD got a new entry).
So you can already do what you want to do, but wrapping it in a single
porcelain might still be useful because it's obviously a lot easier and
safer that way. That said, I wonder what kind of workflow you're using
though, and why you require that feature. I've never needed something
like that.
> 2. interprets "foo" as branch name as opposed to
> revision range.
Well, a single committish is a "range" as far as the range-based
commands are concerned, e.g. "git log master" treats "master" to mean
all commits reachable it. If "rebase --revisions master" would do the
same, that's at least consistent (and for single commit picks, there's
already cherry-pick). The problem with your patch is that it passes the
revision argument to format-patch as is, and:
git format-patch foo
is the same as
git format-patch foo..HEAD
> OTOH, rebase --revisions as I implemented is a "smarter cherry-pick"
> which can't easily be achieved with existing commands, especially if
> you add "-i".
And that "is a 'smarter cherry-pick'" is why I think that rebase is
actually the wrong command to get that feature. While rebase internally
does just mass-cherry-picking, it does that with commits in the current
branch onto a specified branch. The --revisions flag makes it do things
the other way around.
Björn
^ permalink raw reply
* Re: help: bisect single file from repos
From: Junio C Hamano @ 2009-12-08 18:35 UTC (permalink / raw)
To: git; +Cc: Christian Couder, Michael J Gruber, wharms
In-Reply-To: <4B1E5796.2090201@bfs.de>
walter harms <wharms@bfs.de> writes:
> Christian Couder schrieb:
> ...
> i am sorry, i am not familiar with git and when i am stating i am looking
> for examples first. the examples in my man page are like
> git bisect start v2.6.20-rc6 v2.6.20-rc4
> there is nothing like:
> git bisect start 6a87a68a6a8 65a76a8a68a7
>
> I ASSUME that you can use tags like "v2.6.20-rc6" and commit-id like "6a87a68a6a8"
> interchangeable but that was not clear from beginning.
The misconception here is "naming commit is done completely differently
from naming branches and tags", which is false in the git land, but it may
hold true in some other systems (e.g. Subversion, which made them into
different dimensions by making branches and tags into a location in a
larger whole tree namespace when their commits are named by serial version
number of that whole tree namespace).
We can call this a misconception, tell users to learn how things work
before using git (sometimes unlearning CVS and Subversion helps for this
exact reason), dismiss the issue and move on. But I wonder if there is
something we _could_ have done better in the documentation area to avoid
this from the beginning, iow, make it easier to "learn how things work
before using"? I think there is a lesson to be learned by us in here, and
I'd like to hear comments and improvement suggestions, especially from
"usability" and "friendly to new people" advocates.
^ permalink raw reply
* Re: Undoing merges
From: Matthieu Moy @ 2009-12-08 17:48 UTC (permalink / raw)
To: Richard; +Cc: git
In-Reply-To: <8440EA2C12E50645A68C4AA98871665131D8D8@SERVER.webdezign.local>
"Richard" <richard@webdezign.co.uk> writes:
> Hi git list,
>
> I'm trying to find out how to undo a merge.
When sitting on a merge commit,
git reset --merge HEAD^
will undo this merge commit (i.e. pretend the merge has never occured,
at least in your branch). Don't do that if you already published this
merge commit.
> I know that my branches are independent and that I can just carry on
> working on them and merge again later, but I'm just trying to keep
> my revision graph tidier. Should I even be undoing merges?
If it's about cleaning up your history, "git rebase" is your friend,
too (with the same limitation: don't do that on published history). By
default, it does some kind of history flattening.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Undoing merges
From: Richard @ 2009-12-08 17:16 UTC (permalink / raw)
To: git
Hi git list,
I'm trying to find out how to undo a merge. I know that my branches are
independent and that I can just carry on working on them and merge again
later, but I'm just trying to keep my revision graph tidier. Should I
even be undoing merges?
I've searched around, but I can seem to find an answer I can follow.
Regards,
Richard
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Björn Steinbrink @ 2009-12-08 16:37 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git, Junio C Hamano
In-Reply-To: <20091208161406.GB32045@redhat.com>
On 2009.12.08 18:14:07 +0200, Michael S. Tsirkin wrote:
> On Tue, Dec 08, 2009 at 05:08:22PM +0100, Björn Steinbrink wrote:
> > On 2009.12.08 16:47:42 +0200, Michael S. Tsirkin wrote:
> > > Add --revisions flag to rebase, so that it can be used
> > > to apply an arbitrary range of commits on top
> > > of a current branch.
> > >
> > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > ---
> > >
> > > I've been wishing for this functionality for a while now,
> > > so here goes. This isn't yet properly documented and I didn't
> > > write a test, but the patch seems to work fine for me.
> > > Any early flames/feedback?
> >
> > This pretty much reverses what rebase normally does. Instead of "rebase
> > this onto that" it's "'rebase' that onto this". And instead of updating
> > the branch head that got rebased, the, uhm, "upstream" gets updated.
>
> The last sentence is wrong I think - it is still the branch head that
> is updated.
But you don't rebase the branch head. Before the rebase, the branch head
doesn't reference the commits that get rebased. For example:
git checkout bar
git rebase --revisions foo bar
You "rebase" the commits in foo's history, but you update bar.
WRT the result, the above command should be equivalent to:
git checkout bar
git reset --hard foo
git rebase --root --onto ORIG_HEAD;
And here, the commits currently reachable through "bar" are rebased, and
"bar" also gets updated.
Björn
^ permalink raw reply
* Undoing merges
From: rhlee @ 2009-12-08 17:34 UTC (permalink / raw)
To: git
Hi git list,
I hope this isn't a double post. I couldn't get a response from this mailing
list with Outlook.
I'm trying to find out how to undo a merge. I know that my branches are
independent and that I can just carry on working on them and merge again
later, but I'm just trying to keep my revision graph tidier. Should I even
be undoing merges?
I've searched around, but I can seem to find an answer I can follow.
Regards,
Richard
--
View this message in context: http://n2.nabble.com/Undoing-merges-tp4133942p4133942.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH v2 1/3] refactor ref status logic for pushing
From: Daniel Barkalow @ 2009-12-08 17:17 UTC (permalink / raw)
To: Tay Ray Chuan
Cc: git, Shawn O. Pearce, Sverre Rabbelier, Clemens Buchacher,
Jeff King, Junio C Hamano
In-Reply-To: <20091208223543.c7f88afe.rctay89@gmail.com>
On Tue, 8 Dec 2009, Tay Ray Chuan wrote:
> Move the logic that detects up-to-date and non-fast-forward refs to a
> new function in remote.[ch], set_ref_status_for_push().
Is there some reason to not have set_ref_status_for_push() be static in
transport.c now? (Sorry for not suggesting this before.)
Other than that, it looks good to me.
I think it might be a good idea to have it generate a peer ref for refs
that don't have one when mirror is used, which would eliminate a couple
more lines, but there's no reason that has to be done in the same patch.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Michael S. Tsirkin @ 2009-12-08 16:49 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git, Junio C Hamano
In-Reply-To: <20091208164113.GB2005@atjola.homenet>
On Tue, Dec 08, 2009 at 05:41:13PM +0100, Björn Steinbrink wrote:
> On 2009.12.08 18:11:44 +0200, Michael S. Tsirkin wrote:
> > On Tue, Dec 08, 2009 at 05:08:22PM +0100, Björn Steinbrink wrote:
> > > On 2009.12.08 16:47:42 +0200, Michael S. Tsirkin wrote:
> > > > Add --revisions flag to rebase, so that it can be used
> > > > to apply an arbitrary range of commits on top
> > > > of a current branch.
> > > >
> > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > > ---
> > > >
> > > > I've been wishing for this functionality for a while now,
> > > > so here goes. This isn't yet properly documented and I didn't
> > > > write a test, but the patch seems to work fine for me.
> > > > Any early flames/feedback?
> > >
> > > This pretty much reverses what rebase normally does. Instead of "rebase
> > > this onto that" it's "'rebase' that onto this". And instead of updating
> > > the branch head that got rebased, the, uhm, "upstream" gets updated.
> > >
> > > Also, AFAICT this needs to be called like this:
> > > git rebase --revisions foo..bar HEAD
> > >
> > > Changing the meaning of the <upstream> argument and relying on the fact
> > > that <newbase> defaults to <upstream>. If such a thing gets added, it
> > > should rather work like --root, not using <upstream> at all, but --onto
> > > <newbase> only. Maybe defaulting to HEAD for <newbase> and making --onto
> > > optional, as it's reversed WRT what it does compared to the usual
> > > rebase.
> >
> > Sorry, I had trouble parsing the above. Could you suggest e.g. how the
> > help line should look?
>
> Current:
> git rebase [-i | --interactive] [options] [--onto <newbase>]
> <upstream> [<branch>]
> git rebase [-i | --interactive] [options] --onto <newbase>
> --root [<branch>]
>
> Add:
> git rebase [-i | --interactive] [options] --revisions <range> [<branch>]
>
> (Thinking about it, I guess an explicit --onto makes no sense with the
> --revisions flag)
I agree.
So this is different from what I implemented basically only in that
we should disallow combining --onto with --revisions. Right?
> > > But generally, I'd say it would be better to add such a range feature to
> > > cherry-pick than abusing rebase for that.
> >
> > The reason to use rebase is that I often want to combine
> > this with -i flag, editing patches as they are applied.
>
> Hm, well, your patch didn't touch git-rebase--interactive.sh ;-)
>
> Björn
Ah, I was wondering why it doesn't work :)
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Michael S. Tsirkin @ 2009-12-08 16:44 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git, Junio C Hamano
In-Reply-To: <20091208163737.GA2005@atjola.homenet>
On Tue, Dec 08, 2009 at 05:37:37PM +0100, Björn Steinbrink wrote:
> On 2009.12.08 18:14:07 +0200, Michael S. Tsirkin wrote:
> > On Tue, Dec 08, 2009 at 05:08:22PM +0100, Björn Steinbrink wrote:
> > > On 2009.12.08 16:47:42 +0200, Michael S. Tsirkin wrote:
> > > > Add --revisions flag to rebase, so that it can be used
> > > > to apply an arbitrary range of commits on top
> > > > of a current branch.
> > > >
> > > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > > ---
> > > >
> > > > I've been wishing for this functionality for a while now,
> > > > so here goes. This isn't yet properly documented and I didn't
> > > > write a test, but the patch seems to work fine for me.
> > > > Any early flames/feedback?
> > >
> > > This pretty much reverses what rebase normally does. Instead of "rebase
> > > this onto that" it's "'rebase' that onto this". And instead of updating
> > > the branch head that got rebased, the, uhm, "upstream" gets updated.
> >
> > The last sentence is wrong I think - it is still the branch head that
> > is updated.
>
> But you don't rebase the branch head. Before the rebase, the branch head
> doesn't reference the commits that get rebased. For example:
>
> git checkout bar
> git rebase --revisions foo bar
>
> You "rebase" the commits in foo's history, but you update bar.
Yes, that's the who point of the patch. The above applies a single
commit, foo, on top of current branch bar.
> WRT the result, the above command should be equivalent to:
> git checkout bar
> git reset --hard foo
> git rebase --root --onto ORIG_HEAD;
>
> And here, the commits currently reachable through "bar" are rebased, and
> "bar" also gets updated.
>
> Björn
So this
1. won't be very useful, as you show it is easy
to achieve with existing commands.
2. interprets "foo" as branch name as opposed to
revision range.
OTOH, rebase --revisions as I implemented is a "smarter cherry-pick" which
can't easily be achieved with existing commands, especially if you add
"-i".
--
MST
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Björn Steinbrink @ 2009-12-08 16:41 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git, Junio C Hamano
In-Reply-To: <20091208161142.GA32045@redhat.com>
On 2009.12.08 18:11:44 +0200, Michael S. Tsirkin wrote:
> On Tue, Dec 08, 2009 at 05:08:22PM +0100, Björn Steinbrink wrote:
> > On 2009.12.08 16:47:42 +0200, Michael S. Tsirkin wrote:
> > > Add --revisions flag to rebase, so that it can be used
> > > to apply an arbitrary range of commits on top
> > > of a current branch.
> > >
> > > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > > ---
> > >
> > > I've been wishing for this functionality for a while now,
> > > so here goes. This isn't yet properly documented and I didn't
> > > write a test, but the patch seems to work fine for me.
> > > Any early flames/feedback?
> >
> > This pretty much reverses what rebase normally does. Instead of "rebase
> > this onto that" it's "'rebase' that onto this". And instead of updating
> > the branch head that got rebased, the, uhm, "upstream" gets updated.
> >
> > Also, AFAICT this needs to be called like this:
> > git rebase --revisions foo..bar HEAD
> >
> > Changing the meaning of the <upstream> argument and relying on the fact
> > that <newbase> defaults to <upstream>. If such a thing gets added, it
> > should rather work like --root, not using <upstream> at all, but --onto
> > <newbase> only. Maybe defaulting to HEAD for <newbase> and making --onto
> > optional, as it's reversed WRT what it does compared to the usual
> > rebase.
>
> Sorry, I had trouble parsing the above. Could you suggest e.g. how the
> help line should look?
Current:
git rebase [-i | --interactive] [options] [--onto <newbase>]
<upstream> [<branch>]
git rebase [-i | --interactive] [options] --onto <newbase>
--root [<branch>]
Add:
git rebase [-i | --interactive] [options] --revisions <range> [<branch>]
(Thinking about it, I guess an explicit --onto makes no sense with the
--revisions flag)
> > But generally, I'd say it would be better to add such a range feature to
> > cherry-pick than abusing rebase for that.
>
> The reason to use rebase is that I often want to combine
> this with -i flag, editing patches as they are applied.
Hm, well, your patch didn't touch git-rebase--interactive.sh ;-)
Björn
^ permalink raw reply
* PATCH/RFC] gitweb.js: Workaround for IE8 bug
From: Jakub Narebski @ 2009-12-08 16:29 UTC (permalink / raw)
To: Stephen Boyd; +Cc: git
In-Reply-To: <1260148741.1579.50.camel@swboyd-laptop>
On Mon, 7 Dec 2009, Stephen Boyd wrote:
> On Sun, 2009-12-06 at 17:04 -0800, Stephen Boyd wrote:
> >
> > Ok. It's December and I've had some more time to look into this.
> > Initializing 'xhr' to null seems to get rid of the "Unknown error"
> > problem (see patch below).
> >
>
> Ah sorry. Seems this doesn't work and I was just getting lucky.
Does the following fixes the issue for IE8 for you (it works for me)?
As for testing, try with blaming 'revision.c' and 'gitweb/gitweb.perl'
using 'blame_incremental' view.
With probably too long commit message, and not detailed enough title:
-- >8 --
Subject: [PATCH] gitweb.js: Workaround for IE8 bug
In Internet Explorer 8 (IE8) the 'blame_incremental' view, which uses
JavaScript to generate blame info using AJAX, sometimes hang at the
beginning (at 0%) of blaming, e.g. for larger files with long history
like git's own gitweb/gitweb.perl.
The error shown by JavaScript console is "Unspecified error" at char:2
of the following line in gitweb/gitweb.js:
if (xhr.readyState === 3 && xhr.status !== 200) {
Debugging it using IE8 JScript debuger shown that the error occurs
when trying to access xhr.status (xhr is XMLHttpRequest object).
Watch for xhr object shows 'Unspecified error.' as "value" of
xhr.status, and trying to access xhr.status from console throws error.
This bug is some intermittent bug, depending on XMLHttpRequest timing,
as it doesn't occur in all cases. It is probably caused by the fact
that handleResponse is called from timer (pollTimer), to work around
the fact that some browsers call onreadystatechange handler only once
for each state change, and not like required for 'blame_incremental'
as soon as new data is available from server. It looks like xhr
object is not properly initialized; still it is a bug to throw an
error when accessing xhr.status (and not use 'null' or 'undefined' as
value).
Work around this bug in IE8 by using try-catch block when accessing
xhr.status.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
gitweb/gitweb.js | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.js b/gitweb/gitweb.js
index 2a25b7c..9c66928 100644
--- a/gitweb/gitweb.js
+++ b/gitweb/gitweb.js
@@ -779,7 +779,12 @@ function handleResponse() {
}
// the server returned error
- if (xhr.readyState === 3 && xhr.status !== 200) {
+ // try ... catch block is to work around bug in IE8
+ try {
+ if (xhr.readyState === 3 && xhr.status !== 200) {
+ return;
+ }
+ } catch (e) {
return;
}
if (xhr.readyState === 4 && xhr.status !== 200) {
--
1.6.5.3
^ permalink raw reply related
* Re: [PATCH RFC] rebase: add --revisions flag
From: Michael S. Tsirkin @ 2009-12-08 16:14 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git, Junio C Hamano
In-Reply-To: <20091208160822.GA1299@atjola.homenet>
On Tue, Dec 08, 2009 at 05:08:22PM +0100, Björn Steinbrink wrote:
> On 2009.12.08 16:47:42 +0200, Michael S. Tsirkin wrote:
> > Add --revisions flag to rebase, so that it can be used
> > to apply an arbitrary range of commits on top
> > of a current branch.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> >
> > I've been wishing for this functionality for a while now,
> > so here goes. This isn't yet properly documented and I didn't
> > write a test, but the patch seems to work fine for me.
> > Any early flames/feedback?
>
> This pretty much reverses what rebase normally does. Instead of "rebase
> this onto that" it's "'rebase' that onto this". And instead of updating
> the branch head that got rebased, the, uhm, "upstream" gets updated.
The last sentence is wrong I think - it is still the branch head that
is updated.
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Michael S. Tsirkin @ 2009-12-08 16:11 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git, Junio C Hamano
In-Reply-To: <20091208160822.GA1299@atjola.homenet>
On Tue, Dec 08, 2009 at 05:08:22PM +0100, Björn Steinbrink wrote:
> On 2009.12.08 16:47:42 +0200, Michael S. Tsirkin wrote:
> > Add --revisions flag to rebase, so that it can be used
> > to apply an arbitrary range of commits on top
> > of a current branch.
> >
> > Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> > ---
> >
> > I've been wishing for this functionality for a while now,
> > so here goes. This isn't yet properly documented and I didn't
> > write a test, but the patch seems to work fine for me.
> > Any early flames/feedback?
>
> This pretty much reverses what rebase normally does. Instead of "rebase
> this onto that" it's "'rebase' that onto this". And instead of updating
> the branch head that got rebased, the, uhm, "upstream" gets updated.
>
> Also, AFAICT this needs to be called like this:
> git rebase --revisions foo..bar HEAD
>
> Changing the meaning of the <upstream> argument and relying on the fact
> that <newbase> defaults to <upstream>. If such a thing gets added, it
> should rather work like --root, not using <upstream> at all, but --onto
> <newbase> only. Maybe defaulting to HEAD for <newbase> and making --onto
> optional, as it's reversed WRT what it does compared to the usual
> rebase.
Sorry, I had trouble parsing the above. Could you suggest e.g. how the
help line should look?
> But generally, I'd say it would be better to add such a range feature to
> cherry-pick than abusing rebase for that.
>
> Björn
The reason to use rebase is that I often want to combine
this with -i flag, editing patches as they are applied.
--
MST
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Björn Steinbrink @ 2009-12-08 16:08 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git, Junio C Hamano
In-Reply-To: <20091208144740.GA30830@redhat.com>
On 2009.12.08 16:47:42 +0200, Michael S. Tsirkin wrote:
> Add --revisions flag to rebase, so that it can be used
> to apply an arbitrary range of commits on top
> of a current branch.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
> ---
>
> I've been wishing for this functionality for a while now,
> so here goes. This isn't yet properly documented and I didn't
> write a test, but the patch seems to work fine for me.
> Any early flames/feedback?
This pretty much reverses what rebase normally does. Instead of "rebase
this onto that" it's "'rebase' that onto this". And instead of updating
the branch head that got rebased, the, uhm, "upstream" gets updated.
Also, AFAICT this needs to be called like this:
git rebase --revisions foo..bar HEAD
Changing the meaning of the <upstream> argument and relying on the fact
that <newbase> defaults to <upstream>. If such a thing gets added, it
should rather work like --root, not using <upstream> at all, but --onto
<newbase> only. Maybe defaulting to HEAD for <newbase> and making --onto
optional, as it's reversed WRT what it does compared to the usual
rebase.
But generally, I'd say it would be better to add such a range feature to
cherry-pick than abusing rebase for that.
Björn
^ permalink raw reply
* Re: [PATCH 2/2] t7508-status: test all modes with color
From: Michael J Gruber @ 2009-12-08 16:06 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <hflc82$sf8$1@ger.gmane.org>
Jakub Narebski venit, vidit, dixit 08.12.2009 12:10:
> Michael J Gruber wrote:
>
>> +decrypt_color () {
>> + sed \
>> + -e 's/.\[1m/<WHITE>/g' \
>> + -e 's/.\[31m/<RED>/g' \
>> + -e 's/.\[32m/<GREEN>/g' \
>> + -e 's/.\[34m/<BLUE>/g' \
>> + -e 's/.\[m/<RESET>/g'
>> +}
>
> Shouldn't this be better in test-lib.sh, or some common lib
> (lib-color.sh or color-lib.sh; we are unfortunately a bit inconsistent
> in naming here)?
Well, so far it's used in two places (and somewhat differently). I would
say test-libification starts at 3 :)
Michael
^ permalink raw reply
* [PATCH 2/2] gitk-git: have make uninstall also remove empty directories
From: Jan Nieuwenhuizen @ 2009-12-08 15:23 UTC (permalink / raw)
To: git
The default Git install performs a multi-rooted install in $HOME,
which makes manual removal somewhat cumbersome.
The directories created by the installation should be removed if
they are empty.
Signed-off-by: Jan Nieuwenhuizen <janneke@gnu.org>
---
gitk-git/Makefile | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/gitk-git/Makefile b/gitk-git/Makefile
index e1b6045..d68f19a 100644
--- a/gitk-git/Makefile
+++ b/gitk-git/Makefile
@@ -47,6 +47,8 @@ install:: all
uninstall::
$(foreach p,$(ALL_MSGFILES), $(RM) '$(DESTDIR_SQ)$(msgsdir_SQ)'/$(notdir $p) &&) true
$(RM) '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
+ -rmdir -p '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
+ -rmdir -p '$(DESTDIR_SQ)$(msgsdir_SQ)'
clean::
$(RM) gitk-wish po/*.msg
--
1.6.5.2.182.g1a756
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl | http://lilypond.org
^ permalink raw reply related
* [PATCH 1/2] Add/resurrect make uninstall target
From: Jan Nieuwenhuizen @ 2009-12-08 15:23 UTC (permalink / raw)
To: git
Uninstall is a common make target that users may expect to be present,
e.g. it is provided automatically by automake.
The default Git install performs a multi-rooted install in $HOME,
which makes manual removal somewhat cumbersome.
The uninstall target was not present in the toplevel makefile,
only a few other makefiles had partial uninstall targets.
Signed-off-by: Jan Nieuwenhuizen <janneke@gnu.org>
---
Makefile | 18 +++++++++++++++++-
perl/Makefile | 2 +-
templates/Makefile | 5 +++++
3 files changed, 23 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 4a1e5bc..b9ef172 100644
--- a/Makefile
+++ b/Makefile
@@ -1842,7 +1842,23 @@ quick-install-man:
quick-install-html:
$(MAKE) -C Documentation quick-install-html
+bindir_PROGRAMS = git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X git-shell$X git-cvsserver
+uninstall:
+ifndef NO_TCLTK
+ $(MAKE) -C gitk-git uninstall
+ $(MAKE) -C git-gui gitexecdir='$(gitexec_instdir_SQ)' uninstall
+endif
+ifndef NO_PERL
+ $(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' uninstall
+endif
+ $(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' uninstall
+ $(RM) $(ALL_PROGRAMS:%='$(DESTDIR_SQ)$(gitexec_instdir_SQ)'/%)
+ $(RM) $(BUILT_INS:%='$(DESTDIR_SQ)$(gitexec_instdir_SQ)'/%)
+ $(RM) $(OTHER_PROGRAMS:%='$(DESTDIR_SQ)$(gitexec_instdir_SQ)'/%)
+ -rmdir -p '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+ $(RM) $(bindir_PROGRAMS:%='$(DESTDIR_SQ)$(bindir_SQ)'/%)
+ -rmdir -p '$(DESTDIR_SQ)$(bindir_SQ)'
### Maintainer's dist rules
@@ -1921,7 +1937,7 @@ ifndef NO_TCLTK
endif
$(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-GUI-VARS GIT-BUILD-OPTIONS
-.PHONY: all install clean strip
+.PHONY: all install uninstall clean strip
.PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell
.PHONY: .FORCE-GIT-VERSION-FILE TAGS tags cscope .FORCE-GIT-CFLAGS
.PHONY: .FORCE-GIT-BUILD-OPTIONS
diff --git a/perl/Makefile b/perl/Makefile
index 4ab21d6..25fc304 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -10,7 +10,7 @@ ifndef V
QUIET = @
endif
-all install instlibdir: $(makfile)
+all install instlibdir uninstall: $(makfile)
$(QUIET)$(MAKE) -f $(makfile) $@
clean:
diff --git a/templates/Makefile b/templates/Makefile
index 408f013..f4048d9 100644
--- a/templates/Makefile
+++ b/templates/Makefile
@@ -51,3 +51,8 @@ install: all
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(template_instdir_SQ)'
(cd blt && $(TAR) cf - .) | \
(cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xof -)
+
+uninstall:
+ -(cd blt && find . -type f) | (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && xargs $(RM))
+ -(cd blt && find . -mindepth 1 -type d) | (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && xargs rmdir)
+ -rmdir -p '$(DESTDIR_SQ)$(template_instdir_SQ)'
--
1.6.5.2.182.g1a756
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl | http://lilypond.org
^ permalink raw reply related
* Re: Git GUI client SmartGit released
From: Alexander Kitaev @ 2009-12-08 14:17 UTC (permalink / raw)
To: Marc Strapetz; +Cc: Shawn O. Pearce, git
In-Reply-To: <4B16D8F8.90804@syntevo.com>
Hello,
>> I'm curious, did you guys replace JSch because its a pile of junk?
Above statement describes the reason behind my decision to use Trilead
SSH instead of JSCH more or less precisely.
In particular, version of JSCH we were using, used to work extremely
unreliable in case multiple channels within same connection were used
simultaneously. And code quality of JSCH didn't allow me to fix this and
other JSch issues in reasonable time.
Alexander Kitaev,
TMate Software,
http://svnkit.com/ - Java [Sub]Versioning Library!
http://sqljet.com/ - Java SQLite Library!
Marc Strapetz wrote:
>> I noticed you use JGit and the Trilead SSH client.
>>
>> I'm curious, did you guys replace JSch because its a pile of junk?
>> Did you patch JGit to use Trilead SSH instead of JSch? If so,
>> would you be interested in contributing that change back to JGit?
>> I'm rather fed up with JSch... :-)
>
> We currently don't use JGit's transport, but we plant a custom SSH
> client on the git executable which connects back to SmartGit and just
> tunnels SSH data through. Anyway, I can remember that SVNKit was using
> JSch initially and they switched to Trilead because of problems with
> JSch (maybe Alexander in Cc can shed more light on that).
>
> --
> Best regards,
> Marc Strapetz
> =============
> syntevo GmbH
> http://www.syntevo.com
> http://blog.syntevo.com
>
>
>
> Shawn O. Pearce wrote:
>> Marc Strapetz <marc.strapetz@syntevo.com> wrote:
>>> We are proud to announce the general availability of our Git client
>>> SmartGit[1]:
>>>
>>> http://www.syntevo.com/smartgit/index.html
>> Congrats on your release.
>>
>> I noticed you use JGit and the Trilead SSH client.
>>
>> I'm curious, did you guys replace JSch because its a pile of junk?
>> Did you patch JGit to use Trilead SSH instead of JSch? If so,
>> would you be interested in contributing that change back to JGit?
>> I'm rather fed up with JSch... :-)
>>
>
^ permalink raw reply
* Re: [PATCH] Add/resurrect make uninstall target
From: Miklos Vajna @ 2009-12-08 14:57 UTC (permalink / raw)
To: Jan Nieuwenhuizen; +Cc: git
In-Reply-To: <1260283831.1856.43.camel@vuurvlieg>
[-- Attachment #1: Type: text/plain, Size: 385 bytes --]
On Tue, Dec 08, 2009 at 03:50:31PM +0100, Jan Nieuwenhuizen <janneke-list@xs4all.nl> wrote:
> Makefile | 18 +++++++++++++++++-
> gitk-git/Makefile | 2 ++
> perl/Makefile | 2 +-
> templates/Makefile | 5 +++++
> 4 files changed, 25 insertions(+), 2 deletions(-)
I think the gitk-git one should be a separate patch and then Paul can
apply it to gitk.git.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] Add/resurrect make uninstall target
From: Jan Nieuwenhuizen @ 2009-12-08 14:50 UTC (permalink / raw)
To: git
Uninstall is a common make target that users may expect to be present,
e.g. it is provided automatically by automake.
The default Git install performs a multi-rooted installation in $HOME,
which makes manual removing somewhat cumbersome.
The uninstall target was not present in the toplevel makefile,
only a few other makefiles had partial uninstall targets.
Signed-off-by: Jan Nieuwenhuizen <janneke@gnu.org>
---
Makefile | 18 +++++++++++++++++-
gitk-git/Makefile | 2 ++
perl/Makefile | 2 +-
templates/Makefile | 5 +++++
4 files changed, 25 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 4a1e5bc..b9ef172 100644
--- a/Makefile
+++ b/Makefile
@@ -1842,7 +1842,23 @@ quick-install-man:
quick-install-html:
$(MAKE) -C Documentation quick-install-html
+bindir_PROGRAMS = git$X git-upload-pack$X git-receive-pack$X git-upload-archive$X git-shell$X git-cvsserver
+uninstall:
+ifndef NO_TCLTK
+ $(MAKE) -C gitk-git uninstall
+ $(MAKE) -C git-gui gitexecdir='$(gitexec_instdir_SQ)' uninstall
+endif
+ifndef NO_PERL
+ $(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' uninstall
+endif
+ $(MAKE) -C templates DESTDIR='$(DESTDIR_SQ)' uninstall
+ $(RM) $(ALL_PROGRAMS:%='$(DESTDIR_SQ)$(gitexec_instdir_SQ)'/%)
+ $(RM) $(BUILT_INS:%='$(DESTDIR_SQ)$(gitexec_instdir_SQ)'/%)
+ $(RM) $(OTHER_PROGRAMS:%='$(DESTDIR_SQ)$(gitexec_instdir_SQ)'/%)
+ -rmdir -p '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
+ $(RM) $(bindir_PROGRAMS:%='$(DESTDIR_SQ)$(bindir_SQ)'/%)
+ -rmdir -p '$(DESTDIR_SQ)$(bindir_SQ)'
### Maintainer's dist rules
@@ -1921,7 +1937,7 @@ ifndef NO_TCLTK
endif
$(RM) GIT-VERSION-FILE GIT-CFLAGS GIT-GUI-VARS GIT-BUILD-OPTIONS
-.PHONY: all install clean strip
+.PHONY: all install uninstall clean strip
.PHONY: shell_compatibility_test please_set_SHELL_PATH_to_a_more_modern_shell
.PHONY: .FORCE-GIT-VERSION-FILE TAGS tags cscope .FORCE-GIT-CFLAGS
.PHONY: .FORCE-GIT-BUILD-OPTIONS
diff --git a/gitk-git/Makefile b/gitk-git/Makefile
index e1b6045..d68f19a 100644
--- a/gitk-git/Makefile
+++ b/gitk-git/Makefile
@@ -47,6 +47,8 @@ install:: all
uninstall::
$(foreach p,$(ALL_MSGFILES), $(RM) '$(DESTDIR_SQ)$(msgsdir_SQ)'/$(notdir $p) &&) true
$(RM) '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
+ -rmdir -p '$(DESTDIR_SQ)$(bindir_SQ)'/gitk
+ -rmdir -p '$(DESTDIR_SQ)$(msgsdir_SQ)'
clean::
$(RM) gitk-wish po/*.msg
diff --git a/perl/Makefile b/perl/Makefile
index 4ab21d6..25fc304 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -10,7 +10,7 @@ ifndef V
QUIET = @
endif
-all install instlibdir: $(makfile)
+all install instlibdir uninstall: $(makfile)
$(QUIET)$(MAKE) -f $(makfile) $@
clean:
diff --git a/templates/Makefile b/templates/Makefile
index 408f013..f4048d9 100644
--- a/templates/Makefile
+++ b/templates/Makefile
@@ -51,3 +51,8 @@ install: all
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(template_instdir_SQ)'
(cd blt && $(TAR) cf - .) | \
(cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && umask 022 && $(TAR) xof -)
+
+uninstall:
+ -(cd blt && find . -type f) | (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && xargs $(RM))
+ -(cd blt && find . -mindepth 1 -type d) | (cd '$(DESTDIR_SQ)$(template_instdir_SQ)' && xargs rmdir)
+ -rmdir -p '$(DESTDIR_SQ)$(template_instdir_SQ)'
--
1.6.5.2.182.g1a756
--
Jan Nieuwenhuizen <janneke@gnu.org> | GNU LilyPond - The music typesetter
Avatar®: http://AvatarAcademy.nl | http://lilypond.org
^ permalink raw reply related
* [PATCH RFC] rebase: add --revisions flag
From: Michael S. Tsirkin @ 2009-12-08 14:47 UTC (permalink / raw)
To: git, Junio C Hamano
Add --revisions flag to rebase, so that it can be used
to apply an arbitrary range of commits on top
of a current branch.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
I've been wishing for this functionality for a while now,
so here goes. This isn't yet properly documented and I didn't
write a test, but the patch seems to work fine for me.
Any early flames/feedback?
git-rebase.sh | 36 ++++++++++++++++++++++++------------
1 files changed, 24 insertions(+), 12 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index b121f45..d99d04b 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -3,12 +3,13 @@
# Copyright (c) 2005 Junio C Hamano.
#
-USAGE='[--interactive | -i] [-v] [--force-rebase | -f] [--onto <newbase>] [<upstream>|--root] [<branch>] [--quiet | -q]'
+USAGE='[--interactive | -i] [-v] [--force-rebase | -f] [--onto <newbase>] [--revisions <revision range>] [<upstream>|--root] [<branch>] [--quiet | -q]'
LONG_USAGE='git-rebase replaces <branch> with a new branch of the
same name. When the --onto option is provided the new branch starts
out with a HEAD equal to <newbase>, otherwise it is equal to <upstream>
It then attempts to create a new commit for each commit from the original
-<branch> that does not exist in the <upstream> branch.
+<branch> that does not exist in the <upstream> branch, or for
+each commit matching <revision range> when the --revisions options is provided.
It is possible that a merge failure will prevent this process from being
completely automatic. You will have to resolve any such merge failure
@@ -41,6 +42,7 @@ If you would prefer to skip this patch, instead run \"git rebase --skip\".
To restore the original branch and stop rebasing run \"git rebase --abort\".
"
unset newbase
+unset revisions
strategy=recursive
do_merge=
dotest="$GIT_DIR"/rebase-merge
@@ -291,6 +293,11 @@ do
newbase="$2"
shift
;;
+ --revisions)
+ test 2 -le "$#" || usage
+ revisions="$2"
+ shift
+ ;;
-M|-m|--m|--me|--mer|--merg|--merge)
do_merge=t
;;
@@ -459,12 +466,24 @@ case "$#" in
esac
orig_head=$branch
+if test -z "$revisions"
+then
+ if test -n "$rebase_root"
+ then
+ revisions="$onto..$orig_head"
+ else
+ revisions="$upstream..$orig_head"
+ fi
+ mb=$(git merge-base "$onto" "$branch")
+else
+ mb=""
+fi
+
# Now we are rebasing commits $upstream..$branch (or with --root,
# everything leading up to $branch) on top of $onto
# Check if we are already based on $onto with linear history,
# but this should be done only when upstream and onto are the same.
-mb=$(git merge-base "$onto" "$branch")
if test "$upstream" = "$onto" && test "$mb" = "$onto" &&
# linear history?
! (git rev-list --parents "$onto".."$branch" | sane_grep " .* ") > /dev/null
@@ -489,10 +508,10 @@ if test -n "$diffstat"
then
if test -n "$verbose"
then
- echo "Changes from $mb to $onto:"
+ echo "Changes $revisions:"
fi
# We want color (if set), but no pager
- GIT_PAGER='' git diff --stat --summary "$mb" "$onto"
+ GIT_PAGER='' git diff --stat --summary "$revisions"
fi
# If the $onto is a proper descendant of the tip of the branch, then
@@ -504,13 +523,6 @@ then
exit 0
fi
-if test -n "$rebase_root"
-then
- revisions="$onto..$orig_head"
-else
- revisions="$upstream..$orig_head"
-fi
-
if test -z "$do_merge"
then
git format-patch -k --stdout --full-index --ignore-if-in-upstream \
--
1.6.6.rc1.43.gf55cc
^ permalink raw reply related
* Re: [PATCH 0/3] Add a "fix" command to "rebase --interactive"
From: Matthieu Moy @ 2009-12-08 14:39 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Junio C Hamano, Johannes Schindelin, Michael J Gruber,
Michael Haggerty, git
In-Reply-To: <20091208121314.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Teach a new option, --autosquash, to the interactive rebase.
> When the commit log message begins with "!fixup ...", and there
> is a commit whose title begins with the same ...
You should be clearer than "title" here. My understanding is that this
is the _message_ (man git-commit talks about log message or commit
message).
It's a detail, but I could make sense to allow putting something other
than the commit message here, like an object name:
git commit -m "fixup! 66eb61bd"
git commit -m "fixup! HEAD^^"
The last one is a bit tricky, since it should mean "HEAD^^" right
before I did the commit.
All that said, I probably won't be a user of that particular feature
(although I love the new "fixup" command for rebase -i), so don't see
any complaint here, just food for thoughts ;-).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [PATCH v2 3/3] transport-helper.c::push_refs(): emit "no refs" error message
From: Tay Ray Chuan @ 2009-12-08 14:37 UTC (permalink / raw)
To: git
Cc: Shawn O. Pearce, Daniel Barkalow, Sverre Rabbelier,
Clemens Buchacher, Jeff King, Junio C Hamano
In-Reply-To: <20091208223413.98e99d3e.rctay89@gmail.com>
Emit an error message when remote_refs is not set.
This behaviour is consistent with that of builtin-send-pack.c and
http-push.c.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
transport-helper.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
index 6b1f778..96fc48b 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -321,8 +321,11 @@ static int push_refs(struct transport *transport,
struct child_process *helper;
struct ref *ref;
- if (!remote_refs)
+ if (!remote_refs) {
+ fprintf(stderr, "No refs in common and none specified; doing nothing.\n"
+ "Perhaps you should specify a branch such as 'master'.\n");
return 0;
+ }
helper = get_helper(transport);
if (!data->push)
--
1.6.4.4
^ permalink raw reply related
* Re: [BUG] Bad msysgit/egit interaction over dotfiles
From: Yann Dirson @ 2009-12-08 14:37 UTC (permalink / raw)
To: kusmabite; +Cc: Ferry Huberts, GIT ml
In-Reply-To: <40aa078e0912080623q108b2affk80534ccd5fd7ace3@mail.gmail.com>
On Tue, Dec 08, 2009 at 03:23:55PM +0100, Erik Faye-Lund wrote:
> On Tue, Dec 8, 2009 at 2:42 PM, Ferry Huberts <ferry.huberts@pelagic.nl> wrote:
> > On 12/08/2009 02:34 PM, Erik Faye-Lund wrote:
> >> On Tue, Dec 8, 2009 at 2:28 PM, Yann Dirson <ydirson@linagora.com> wrote:
> >>> I'm not sure who's at fault here - namely, I can't see any valid
> >>> reason for eclipse to refuse such writes, but I am not sure it is a
> >>> good reason for msysgit would set the hidden bit either. In either
> >>> case, even if only for the short term, I think msysgit should ensure
> >>> that this bit does not get set (possibly circumventing any magic msys
> >>> would do behind its back).
> >>
> >> Setting the config option "core.hidedotfiles" to "false" should
> >> prevent this from happening.
Right, it works much better this way.
> > why isn't this the default?
> >
> > I also experienced this change in behaviour and I thought we would
> > strive to keep the experience the same.
> >
>
> You can follow the discussion here:
> http://code.google.com/p/msysgit/issues/detail?id=288
>
> I believe the reason is something like "because someone suggested it,
> and no one disagreed". Do you have a good argument why it shouldn't be
> the default (other than "it's a change", because changing it back now
> would also be a change)?
Depending on the opinion of the Eclipse guys on this issue about
"writing to hidden files only says 'could not write'", which arguably
could be seen as a bug on their side, we can see changing this
behaviour back to the default on the msysgit side as either a
(possibly temporary) workaround for a known eclipse bug, or as getting
again interoperable with egit.
Note that I did not get time yet to fully investigate the eclipse
status on the issue.
Best regards,
--
Yann
^ permalink raw reply
* [PATCH v2 2/3] transport.c::transport_push(): make ref status affect return value
From: Tay Ray Chuan @ 2009-12-08 14:36 UTC (permalink / raw)
To: git
Cc: Shawn O. Pearce, Daniel Barkalow, Sverre Rabbelier,
Clemens Buchacher, Jeff King, Junio C Hamano
In-Reply-To: <20091208223413.98e99d3e.rctay89@gmail.com>
Use push_had_errors() to check the refs for errors and modify the
return value.
Signed-off-by: Tay Ray Chuan <rctay89@gmail.com>
---
Rewrote this.
transport.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/transport.c b/transport.c
index 12c4423..9b23989 100644
--- a/transport.c
+++ b/transport.c
@@ -875,7 +875,7 @@ int transport_push(struct transport *transport,
int verbose = flags & TRANSPORT_PUSH_VERBOSE;
int quiet = flags & TRANSPORT_PUSH_QUIET;
int porcelain = flags & TRANSPORT_PUSH_PORCELAIN;
- int ret;
+ int ret, err;
if (flags & TRANSPORT_PUSH_ALL)
match_flags |= MATCH_REFS_ALL;
@@ -892,8 +892,11 @@ int transport_push(struct transport *transport,
flags & TRANSPORT_PUSH_FORCE);
ret = transport->push_refs(transport, remote_refs, flags);
+ err = push_had_errors(remote_refs);
- if (!quiet || push_had_errors(remote_refs))
+ ret |= err;
+
+ if (!quiet || err)
print_push_status(transport->url, remote_refs,
verbose | porcelain, porcelain,
nonfastforward);
--
1.6.4.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox