* Re: Generating patches/Cherry Picking for a large number of commits
From: Jeff King @ 2009-08-28 21:54 UTC (permalink / raw)
To: Alydis; +Cc: git
In-Reply-To: <ae09c2a40908281250r42275a3o96825b89e725bace@mail.gmail.com>
On Fri, Aug 28, 2009 at 02:50:53PM -0500, Alydis wrote:
> While I have your attention, however, I noticed that git am <path>
> will apply the list patches generated by format-patch. The
> documentation said something about mbox/maildir directories, which I
> actually am not that familiar with. Is it safe to say that git am
> <path> will read the path and apply patches in numerical order? Does
> it allow skipping?
It will apply the patches in the order given on the command line. When
your shell expands the "patches/*" glob, it will do so in lexically
sorted order. Meaning "0001" comes before "0002", etc, which is the
reason that format-patch zero-pads the filenames.
You can edit or delete the patches in your patch directory before
applying, and they should apply the same (unless you create a patch that
cannot actually be applied).
-Peff
^ permalink raw reply
* Re: [PATCH] Round-down years in "years+months" relative date view
From: A Large Angry SCM @ 2009-08-28 22:01 UTC (permalink / raw)
To: Jeff King; +Cc: Alex Riesen, David Reiss, git
In-Reply-To: <20090828171552.GA6821@coredump.intra.peff.net>
Jeff King wrote:
> On Fri, Aug 28, 2009 at 07:00:59PM +0200, Alex Riesen wrote:
>
>> On Fri, Aug 28, 2009 at 17:02, Jeff King<peff@peff.net> wrote:
>>> But that's the point: you can't do that without a race condition. Your
>>> test gets a sense of the current time, then runs git, which checks the
>>> current time again. How many seconds elapsed between the two checks?
>> How _many_ do you need?
>
> I don't understand what you're trying to say. My point is that if you
> are checking results to a one-second precision, you need to know whether
> zero seconds elapsed, or one second, or two seconds, or whatever to get
> a consistent result.
To no-one in particular, Gitzilla mumbles "To do this right(tm) would
probably require LD_PRELOAD magic with a environment variable invocation.
^ permalink raw reply
* Re: Using git to track my PhD thesis, couple of questions
From: demerphq @ 2009-08-28 22:16 UTC (permalink / raw)
To: david; +Cc: seanh, git
In-Reply-To: <alpine.DEB.2.00.0908281443070.28411@asgard.lang.hm>
2009/8/28 <david@lang.hm>:
> On Fri, 28 Aug 2009, demerphq wrote:
>
>> 2009/8/28 seanh <seanh.nospam@gmail.com>:
>>>
>>> On Fri, Aug 28, 2009 at 12:21:42AM +0200, demerphq wrote:
>>>>
>>>> As you can generate the PDF's from the latex then just hack gitweb to
>>>> let them download it from there.
>>>
>>> Unfortunately gitweb is written in Perl. But I know what you mean, it
>>> should in theory be possible for them to click on a 'Get PDF' link for a
>>> particular revision that causes the PDF to be built and returned to
>>> their browser.
>>
>> What is unfortunate about that? Perl is a duct tape/swiss-army-knife
>> of the internet. Hacking gitweb to generate PDF's on the fly from
>> latex documents should be a fairly trivial hack, even if you aren't a
>> Perl hacker.
>
> I have a situation where I need to generae pdf's from files that are under
> git. I have a git repository on by webserver that I push to and have a
> trigger that regenerates the pdfs any time there is a push.
Actually this discussion makes me think that there is room for a hack
to gitweb to provide extensible and pluggable renderers of the files
in a repository. Such a framework would for instance provide for
syntax highlighting, PDF generation from latex files, etc.
Hypothetically it wouldnt be too hard to do. A Win32 (dare I say)
registry of file extensions/shebang lines would be linked into a set
of renderer plugin's, which in turn would automatically add the
required links to render the file as needed. Quite doable actually.
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* Re: Generating patches/Cherry Picking for a large number of commits
From: Junio C Hamano @ 2009-08-28 22:31 UTC (permalink / raw)
To: Alydis; +Cc: Jeff King, git
In-Reply-To: <ae09c2a40908281250r42275a3o96825b89e725bace@mail.gmail.com>
Alydis <alydis@august8.net> writes:
> Ack! Embarrassing RTFM.
>
> While I have your attention, however, I noticed that git am <path>
> will apply the list patches generated by format-patch. The
> documentation said something about mbox/maildir directories, which I
> actually am not that familiar with. Is it safe to say that git am
> <path> will read the path and apply patches in numerical order? Does
> it allow skipping?
If you say "git am <directory>/*", like you have in your original message
shown *below* (sheesh, why am I responding to somebody who top-posts?),
you let your shell perform a numerical sort, so you would be Ok.
>>> git format-patch -o patches v2.6.21..v2.6.30 arch/powerpc/boot
>>> git am -3 patches/*
I do not think the above format-patch, even with --full-diff, is
necessarily a good idea nor would work in general.
Often, when a series is concocted, you would see this pattern:
* Early parts of the patch series to lay groundwork by introducing non
platform specific infrastructure; and then
* Later parts of the series utilizes the infrastructure to implement the
feature for particular platforms.
Obviously you are interested only for powerpc parts in the latter category
and would want to omit anything irrelevant to powerpc. But you do want to
include all of the former class, even if they do not touch anything inside
the powerpc area.
^ permalink raw reply
* [PATCH master] t/test-lib.sh: provide a shell implementation of the 'yes' utility
From: Brandon Casey @ 2009-08-28 22:32 UTC (permalink / raw)
To: gitster; +Cc: git, Brandon Casey
In-Reply-To: <tK_IWVRokJuwYhAJ3h5cvYFUGHzmrYoRPbMxLQUdj2eLINK_28NnVA@cipher.nrlssc.navy.mil>
From: Brandon Casey <drafnel@gmail.com>
Some platforms (IRIX 6.5, Solaris 7) do not provide the 'yes' utility.
Currently, some tests, including t7610 and t9001, try to call this program.
Due to the way the tests are structured, the tests still pass even though
this program is missing. Rather than succeeding by chance, let's provide
an implementation of the simple 'yes' utility in shell for all platforms to
use.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
t/test-lib.sh | 15 +++++++++++++++
1 files changed, 15 insertions(+), 0 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index a5b8d03..f2ca536 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -685,6 +685,21 @@ do
esac
done
+# Provide an implementation of the 'yes' utility
+yes () {
+ if test $# = 0
+ then
+ y=y
+ else
+ y="$*"
+ fi
+
+ while echo "$y"
+ do
+ :
+ done
+}
+
# Fix some commands on Windows
case $(uname -s) in
*MINGW*)
--
1.6.4
^ permalink raw reply related
* Re: Generating patches/Cherry Picking for a large number of commits
From: Junio C Hamano @ 2009-08-28 22:35 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Alydis, Jeff King, git
In-Reply-To: <m3k50nllt6.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> git-format-patch | git-am pipeline has to work correctly, as it
> originally was the way (modulo extra options) git-rebase was
> implemented. So yes, "git am <dir>" should understand and apply in
> correct order result of "git format-patch -o <dir> <revspec>".
You are not making any sense. rebase is done using --stdout and does not
rely on the intermediate files nor ordering of their names.
^ permalink raw reply
* How does git follow branch history across a merge commit?
From: Steven E. Harris @ 2009-08-28 22:37 UTC (permalink / raw)
To: git
This question concerns git's representation of merge commits.
I understand that branches in git are references to commit vertices in a
graph, that each of these vertices have zero or more reference edges to
a parent (predecessor) vertex, and that merges create vertices with at
least two parents. Walking back in time from a branch head involves
traversing parent edges.
But what happens when such traversal reaches a merge commit? If one asks
git to move back, say, in time by a few days, or so many predecessors,
how does it know (or choose) which way to go upon reaching a merge
commit?
I set up an experiment with two competing branches that require merging
back together:
,----
| mkdir gitexp && cd gitexp && git init
| $EDITOR file1.txt
| git add file1.txt
| git commit -m'Initial impound.'
| $EDITOR file1.txt
| git commit -a -m'Added a second line.'
|
| git checkout -b competition
| $EDITOR file1.txt
| git commit -a -m'Extended second line.'
|
| git checkout master
| $EDITOR file1.txt
| git commit -a -m'Added third line.'
|
| git checkout competition
| $EDITOR file1.txt
| git commit -a -m'Edited second line.'
| $EDITOR file1.txt
| git commit -a -m'Added an alternate third line.'
|
| git checkout master
| git merge competition
| # Edit to resolve conflict:
| $EDITOR file1.txt
| git commit -a
|
| git checkout 'HEAD^'
| # At this point, git picked the predecessor along branch "master".
`----
Was it just luck that "HEAD^" referred to the predecessor that came from
branch "master" rather than branch "competition"?
--
Steven E. Harris
^ permalink raw reply
* Re: How does git follow branch history across a merge commit?
From: Junio C Hamano @ 2009-08-28 23:30 UTC (permalink / raw)
To: Steven E. Harris; +Cc: git
In-Reply-To: <8363c75zug.fsf@torus.sehlabs.com>
"Steven E. Harris" <seh@panix.com> writes:
> Was it just luck that "HEAD^" referred to the predecessor that came from
> branch "master" rather than branch "competition"?
Yes, if you want the second parent you would say HEAD^2.
^ permalink raw reply
* Re: How does git follow branch history across a merge commit?
From: Junio C Hamano @ 2009-08-28 23:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steven E. Harris, git
In-Reply-To: <7vskfbcy9n.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "Steven E. Harris" <seh@panix.com> writes:
>
>> Was it just luck that "HEAD^" referred to the predecessor that came from
>> branch "master" rather than branch "competition"?
>
> Yes, if you want the second parent you would say HEAD^2.
Ahh, I misread your question. No, it is not luck. If you merge
competition into your master, the resulting commit will have your master
as its first parent. If check out competition and merge master in your
example, the resulting merge will have compatition as the first parent.
^ permalink raw reply
* Re: How does git follow branch history across a merge commit?
From: Steven E. Harris @ 2009-08-28 23:50 UTC (permalink / raw)
To: git
In-Reply-To: <7vmy5jbjkr.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> If you merge competition into your master, the resulting commit will
> have your master as its first parent. If check out competition and
> merge master in your example, the resulting merge will have
> compatition as the first parent.
I see, having run a few more experiments to confirm this.
I missed the point that merge commits are not "predecessor neutral";
they apparently have a bias indicating "/this branch/ received content
from /that branch/ (or /those branches/)".
To try to recreate my confusing scenario, I tried this:
,----
| git checkout competition
| git merge master
| # This fast-forwarded "competition" be equivalent to "master".
| git checkout 'HEAD^'
| # This wound up again at "master"'s predecessor, not "competition"'s.
`----
It seems that since fast-forward merges don't produce a commit, the
merge record remains in place recording that branch "competition" came
into branch "master". Even though we're checked out to branch
"competition" here, following its history back in time requires some
manual intervention. Do you concur, or is my example perhaps flawed?
--
Steven E. Harris
^ permalink raw reply
* Re: How does git follow branch history across a merge commit?
From: Junio C Hamano @ 2009-08-29 0:01 UTC (permalink / raw)
To: Steven E. Harris; +Cc: git
In-Reply-To: <831vmv5wh7.fsf@torus.sehlabs.com>
"Steven E. Harris" <seh@panix.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> If you merge competition into your master, the resulting commit will
>> have your master as its first parent. If check out competition and
>> merge master in your example, the resulting merge will have
>> compatition as the first parent.
>
> I see, having run a few more experiments to confirm this.
>
> I missed the point that merge commits are not "predecessor neutral";
> they apparently have a bias indicating "/this branch/ received content
> from /that branch/ (or /those branches/)".
We are in principle pretty much neutral, but in certain places you
obviously cannot avoid tiebreaking. A commit object has to record parents
in a bytestream in its representation, and inevitably one parent must come
before another one.
You also must give your users some way to refer to each of its parents, so
naturally we count from one, and call them $it^ (== $it^1), $it^2, etc.
We do not have "$it^?" that lets you pick its parents at random, as we
haven't found a good use case for such a feature.
One place we tiebreak favoring earlier parents over later ones, even
though there is no logical reason to do so, is merge simplification [*1*].
When more than one parents have the same tree, with respect to pathspec
given, while traversing the history, we pick the earliest one, because
that is just as good as choosing one at random, and would give us a
reproducible result. For a similar reason, when blame follows a merge
from identical parents, it assigns blame to earlier parents.
And at the end-user workflow level, people tend to think "I merge others
work into mine", so the log family of commands have --first-parent option
to follow only that ancestry, but that logic kicks in only while browsing,
not while building histories.
[Footnote]
*1* If you do not know what a merge simplification is, refer to e.g.
http://gitster.livejournal.com/35628.html and notice there is a place
where we follow "a parent that is the same as the merge result".
^ permalink raw reply
* Re: git clone http://git.savannah.gnu.org/cgit/xboard.git segfaults
From: Tay Ray Chuan @ 2009-08-29 0:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Ali Polatel, git
In-Reply-To: <20090826131235.GF16486@harikalardiyari>
Hi,
2009/8/26 Ali Polatel <polatel@gmail.com>:
> It works, I don't get any segfaults after applying this patch.
Junio, I hope you don't mind me asking but why hasn't this patch been
accepted? It addresses a pretty severe problem, and the sooner users
have it the better.
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: How does git follow branch history across a merge commit?
From: Björn Steinbrink @ 2009-08-29 0:25 UTC (permalink / raw)
To: Steven E. Harris; +Cc: git
In-Reply-To: <831vmv5wh7.fsf@torus.sehlabs.com>
On 2009.08.28 19:50:44 -0400, Steven E. Harris wrote:
> I missed the point that merge commits are not "predecessor neutral";
> they apparently have a bias indicating "/this branch/ received content
> from /that branch/ (or /those branches/)".
>
> To try to recreate my confusing scenario, I tried this:
>
> ,----
> | git checkout competition
> | git merge master
> | # This fast-forwarded "competition" be equivalent to "master".
> | git checkout 'HEAD^'
> | # This wound up again at "master"'s predecessor, not "competition"'s.
> `----
>
> It seems that since fast-forward merges don't produce a commit, the
> merge record remains in place recording that branch "competition" came
> into branch "master".Even though we're checked out to branch
> "competition" here, following its history back in time requires some
> manual intervention. Do you concur, or is my example perhaps flawed?
As there is no merge commit, there's no "merge record" either.
"competition" just got updated to reference the same commit as "master".
Branch "competition" did not "come into" branch "master" either.
"competition" and "master" are just the names of the branch heads. And
those just reference commits, which actually form the history and have
no record of belonging to any branch head on their own.
IOW: "master" and "competition" aren't branches as in "a series of
commits with a fixed relation to each other", but just branch heads,
referencing the tips where the branches grow.
Scenario A:
Given this history:
A---B---C (master)
\
D---E (competition)
If you now merge "master" to "competition" you get:
A---B---C (master)
\ \
D---E---M (competition)
Where M is a merge commit with two parents, E being the first one, C
being the second one. And that's everything that git knows, that M is a
merged of C and E. That E is the first parent is just a smart choice,
nothing else.
Scenario B:
Given this history:
A (competition)
\
B---C (master)
If you ask git to merge "master" to "competition", it will see that
there aren't any commits reachable through "competition" that aren't
reachable through "master". So simply fast-forwarding "competition won't
make you lose anything. Thus you get:
A---B---C (master) (competition)
There's no trace of any merge, because it wasn't required. You can't
even tell that a fast-forward happened from that history. You could as
well just have created "competition".
That said, if you want to force a merge commit (which can sometimes be
useful), you can use the --no-ff flag:
git checkout competition
git merge --no-ff master
And this leads to:
A------M (competition)
\ /
B---C (master)
With M's first parent being A, and the second parent being C.
(Assuming that "competition" is a topic branch, this would be a bit
weird though, as you produce a totally pointless merge commit, before
you even started working on your topic branch. OTOH doing this the other way
around, i.e. forcing a merge commit when you merge a topic branch to
"master" _can_ be useful. Don't over do it though).
HTH
Björn
^ permalink raw reply
* Re: git clone http://git.savannah.gnu.org/cgit/xboard.git segfaults
From: Junio C Hamano @ 2009-08-29 0:53 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Johannes Schindelin, Ali Polatel, git
In-Reply-To: <be6fef0d0908281707o59fdb0c9h9a5a78864b6ad063@mail.gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
> 2009/8/26 Ali Polatel <polatel@gmail.com>:
>> It works, I don't get any segfaults after applying this patch.
>
> Junio, I hope you don't mind me asking but why hasn't this patch been
> accepted? It addresses a pretty severe problem, and the sooner users
> have it the better.
The procedure ideally goes like this:
(0) original bug report is sent; Ali did this with:
Date: Mon, 17 Aug 2009 16:56:52 +0300
Message-ID: <20090817135651.GA4570@harikalardiyari>
(1) a helpful contributor (or somebody ashamed of having introduced
the bug ;-)) sends a potential fix as an RFT to the reporter, with
Cc: to list. You did this with:
Date: Wed, 26 Aug 2009 20:20:53 +0800
Message-ID: <20090826202053.6e6442a6.rctay89@gmail.com>
This message was clear that it was a request-for-test of a
potential fix, not a "I know this is the correct fix to the
problem; the maintainer, please apply". It wasn't even Cc:'ed to
me, and not CC'ing me is the right thing to do for this kind of
request-for-test patches.
(2) success/failure report is given. Ali did this with:
Date: Wed, 26 Aug 2009 16:12:35 +0300
Message-ID: <20090826131235.GF16486@harikalardiyari>
to report a success.
(3) Upon seeing (2), the sender of (1) submits the final patch for
inclusion, with To: me and CC: list.
The sender makes sure that it is easy for me and others who sees
(3) first without necessarily having followed the earlier
discussions to find the previous messages (i.e. 0, 1, 2). In this
case, sending a follow-up to (2) is sufficient, just like you did
in the message I am responding to, because these three steps were
neatly threaded already.
If you knew the flow I am describing here, you would have sent
"the final patch for inclusion" instead of the message I am
replying to. The final patch for inclusion would have consisted
of:
* The usual "applicable patch": a proper subject, the log message,
your Signed-off-by:, and Tested-by: to credit Ali;
* Optionally, after the three-dash line before the diffstat, any
out-of-band communication, e.g.
"Junio, please apply to 'maint'; this is a fix for a grave bug,
and the problem goes all the way down to version 1.6.1."
* And the diffstat and the diff.
My request for this procedure is not red tape.
While an issue (such as this http one) is resolved that is in an area
(e.g. http) people other than me (i.e. you) are much more familiar with, I
do not have to keep track of the discussion while more capable hands are
on top of it. Having (3) as the concluding step will
- give me a way to easily verify, if I wanted to, the claim that this is
the right solution, by referring to the previous dialog; and
- give you a way to make sure that what is recorded is the correct final
solution (this is especially important if steps 1 and 2 have to be
repeated before reaching the final solution), and that the necessary
background information (e.g. credits to the original reporter) are
given in your own words, instead of having _me_ come up with one with
less-than-perfect understanding of the issues I would gain after
skimming the archive for the previous discussion.
Nobody can expect me to keep track of everything; the final "Here is the
good one" would help the process flow smoothly and reduce the chance of
mistakes.
Thanks.
^ permalink raw reply
* Re: git clone http://git.savannah.gnu.org/cgit/xboard.git segfaults
From: Junio C Hamano @ 2009-08-29 1:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tay Ray Chuan, Johannes Schindelin, Ali Polatel, git
In-Reply-To: <7v8wh35tl8.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Nobody can expect me to keep track of everything; the final "Here is the
> good one" would help the process flow smoothly and reduce the chance of
> mistakes.
I forgot to add...
In this case, it is _now_ clear to me that you consider your
Subject: Re: git clone http://git.... segfaults
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Ali Polatel <polatel@gmail.com>, git@vger.kernel.org
Date: Wed, 26 Aug 2009 20:20:53 +0800
Message-ID: <20090826202053.6e6442a6.rctay89@gmail.com>
to be the final version, so I'd just add "noticed by Ali Polatel who later
tested this patch to verify; Dscho helped to identify the problem spot."
at the end of the commit log message in the message and apply. IOW, no
need to resend.
Ali's original report is about 1.6.4 so I presume this is 'maint'
material, so let's include this in 1.6.4.2.
^ permalink raw reply
* Re: git clone http://git.savannah.gnu.org/cgit/xboard.git segfaults
From: Tay Ray Chuan @ 2009-08-29 2:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Ali Polatel, git
In-Reply-To: <7vprafzap3.fsf@alter.siamese.dyndns.org>
Hi,
On Sat, Aug 29, 2009 at 9:10 AM, Junio C Hamano<gitster@pobox.com> wrote:
> I forgot to add...
>
> In this case, it is _now_ clear to me that you consider your
>
> Subject: Re: git clone http://git.... segfaults
> To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
> Cc: Ali Polatel <polatel@gmail.com>, git@vger.kernel.org
> Date: Wed, 26 Aug 2009 20:20:53 +0800
> Message-ID: <20090826202053.6e6442a6.rctay89@gmail.com>
>
> to be the final version,
(I refer to this and your previous message) Thanks for taking the time
to explain the procedures/workflow involved. Yes, I thought Ali's
report on the patch was sufficient to flag the patch as
here-is-the-good one, but I didn't indicate this to you clearly
enough. Sorry for all the trouble.
> so I'd just add "noticed by Ali Polatel who later
> tested this patch to verify; Dscho helped to identify the problem spot."
> at the end of the commit log message in the message and apply. IOW, no
> need to resend.
Thanks again. Somehow, I neglected to include credits to Ali and Dscho.
--
Cheers,
Ray Chuan
^ permalink raw reply
* git-bz: command line integration for bugzilla
From: Owen Taylor @ 2009-08-29 2:24 UTC (permalink / raw)
To: git
Was filling out the Git user's survey today, and noticed that my git-bz
tool wasn't on the long list of "Git interfaces, implementations,
frontends and tools" - but then again, I've never really advertised it
beyond GNOME IRC. So, I was reminded to mention it here...
The Pitch
=========
Do you use git? You wouldn't be reading this list if you didn't. Do you
use Bugzilla? No? You can stop here.
Since you use Git and you use Bugzilla, you want to use git-bz.
Setup:
git config --global bz.default-tracker bugzilla.example.com
# in some module
git config bz.default-product TiddlyWinks
git config bz.default-component AI-Engine
File a new bug with a commit attached as a patch, rewrite the commit
message to include the URL of the newly filed bug:
git bz file -u HEAD
Attach a series of commits to an existing bug, bringing each up in
an editor to allow editing the comment and picking old patches to
obsolete:
git bz attach -e 43215 HEAD~3..
Apply patches already attached to an existing bug to a local branch:
git bz apply http://bugzilla.example.com/show_bug.cgi?34132
Getting It
==========
The script: http://git.fishsoup.net/cgit/git-bz/plain/git-bz
CGIT: http://git.fishsoup.net/cgit/git-bz
clone: git://git.fishsoup.net/git-bz
It's a standalone Python script, no dependencies, so you can just copy it
or symlink it somewhere in your path.
Notes
=====
* Yes, it's in Python.
* It should work with most Bugzilla installations
* There are some nice things that could be added - support for automatically
creating a branch when applying patches from a bug locally, 'git bz close'
to push patches and close the corresponding Bugzilla bugs, and so forth.
It's pretty good as is.
* The utility of attaching patches to Bugzilla is probably greatest
in a shared-central repository workflow. If all contributors already
are publishing all changes to personal public repositories, then attaching
them to Bugzilla in addition may not make sense.
Tracking merge requests would require a quite different form of Bugzilla
integration (probably server side)
* It used to be command-line compatible with git-format-patch for the handling
of 'git bz file <revision>' - but I switched it at some point so you didn't
need to add '-1' to file a single commit. Still undecided if it's better
to be obvious or to be compatible.
^ permalink raw reply
* Re: [PATCH] upload-pack: add a trigger for post-upload-pack hook
From: Junio C Hamano @ 2009-08-29 6:17 UTC (permalink / raw)
To: Jakub Narebski
Cc: Johan Sorensen, Jeff King, Tom Werner, Tom Preston-Werner, git
In-Reply-To: <m3ws4pl6x7.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
>> I'd like to suggest the following line from the original patch:
>>
>> full-pack integer::
>> 1 if the request was considered a full clone, 0 if it was a
>> partial update (fetch)
>
> If it is all "want" and no "have", it is clone or fetch into empty
> repository. If additionaly "want"s cover all refs, it is a clone.
> No need to pass this information: it can be derived.
Well, not exactly.
Here is an iffy RFC patch. Iffy not in the sense that its implementation
is questionable, but in the sense that I am not really convinced if the
distinction between fetching some (or in the worst case, most) but not all
refs, and fetching full set of refs, into an empty repository is something
worth making.
Does anybody from GitHub have any input? Is there something that can
still improved to suit GitHub's needs?
-- >8 --
Subject: [PATCH] upload-pack: feed "kind [clone|fetch]" to post-upload-pack hook
A request to clone the repository does not give any "have" but asks for
all the refs we offer with "want". When a request does not ask to clone
the repository fully, but asks to fetch some refs into an empty
repository, it will not give any "have" but its "want" won't ask for all
the refs we offer.
If we suppose (and I would say this is a rather big if) that it makes
sense to distinguish these two cases, a hook cannot reliably do this
alone. The hook can detect lack of "have" and bunch of "want", but there
is no direct way to tell if the other end asked for all refs we offered,
or merely most of them.
Between the time we talked with the other end and the time the hook got
called, we may have acquired more refs or lost some refs in the repository
by concurrent operations. Given that we plan to introduce selective
advertisement of refs with a protocol extension, it would become even more
difficult for hooks to guess between these two cases.
This adds "kind [clone|fetch]" to hook's input, as a stable interface to
allow the hooks to tell these cases apart.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Documentation/githooks.txt | 4 ++++
t/t5501-post-upload-pack.sh | 24 ++++++++++++++++++++++--
upload-pack.c | 4 ++++
3 files changed, 30 insertions(+), 2 deletions(-)
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index 036f6c7..c308d29 100644
--- a/Documentation/githooks.txt
+++ b/Documentation/githooks.txt
@@ -332,6 +332,10 @@ time float::
size decimal::
Size of the resulting packfile in bytes.
+kind string:
+ Either "clone" (when the client did not give us any "have", and asked
+ for all our refs with "want"), or "fetch" (otherwise).
+
pre-auto-gc
-----------
diff --git a/t/t5501-post-upload-pack.sh b/t/t5501-post-upload-pack.sh
index 47ee7b5..d89fb51 100755
--- a/t/t5501-post-upload-pack.sh
+++ b/t/t5501-post-upload-pack.sh
@@ -29,7 +29,9 @@ test_expect_success initial '
) &&
want=$(sed -n "s/^want //p" "$LOGFILE") &&
test "$want" = "$(git rev-parse --verify B)" &&
- ! grep "^have " "$LOGFILE"
+ ! grep "^have " "$LOGFILE" &&
+ kind=$(sed -n "s/^kind //p" "$LOGFILE") &&
+ test "$kind" = fetch
'
test_expect_success second '
@@ -43,7 +45,25 @@ test_expect_success second '
want=$(sed -n "s/^want //p" "$LOGFILE") &&
test "$want" = "$(git rev-parse --verify C)" &&
have=$(sed -n "s/^have //p" "$LOGFILE") &&
- test "$have" = "$(git rev-parse --verify B)"
+ test "$have" = "$(git rev-parse --verify B)" &&
+ kind=$(sed -n "s/^kind //p" "$LOGFILE") &&
+ test "$kind" = fetch
+'
+
+test_expect_success all '
+ rm -fr sub &&
+ HERE=$(pwd) &&
+ git init sub &&
+ (
+ cd sub &&
+ git clone "file://$HERE/.git" new
+ ) &&
+ sed -n "s/^want //p" "$LOGFILE" | sort >actual &&
+ git rev-parse A B C | sort >expect &&
+ test_cmp expect actual &&
+ ! grep "^have " "$LOGFILE" &&
+ kind=$(sed -n "s/^kind //p" "$LOGFILE") &&
+ test "$kind" = clone
'
test_done
diff --git a/upload-pack.c b/upload-pack.c
index 857440d..8e82179 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -187,6 +187,10 @@ static int run_post_upload_pack_hook(size_t total, struct timeval *tv)
(long)tv->tv_sec, (long)tv->tv_usec);
if (!err)
err |= feed_msg_to_hook(proc.in, "size %ld\n", (long)total);
+ if (!err)
+ err |= feed_msg_to_hook(proc.in, "kind %s\n",
+ (nr_our_refs == want_obj.nr && !have_obj.nr)
+ ? "clone" : "fetch");
if (close(proc.in))
err = 1;
if (finish_command(&proc))
--
1.6.4.1.307.g70e9f
^ permalink raw reply related
* [PATCH] Remove unused t/t8005/iso8859-5.txt file
From: Nanako Shiraishi, しらいし ななこ @ 2009-08-29 7:16 UTC (permalink / raw)
To: git
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=UTF-8, Size: 676 bytes --]
This file is no longer used since commit 54bc13c.
Signed-off-by: ’¤·’¤é’¤¤’¤· ’¤Ê’¤Ê’¤³ <nanako3@lavabit.com>
---
t/t8005/iso8859-5.txt | Bin 74 -> 0 bytes
1 files changed, 0 insertions(+), 0 deletions(-)
delete mode 100644 t/t8005/iso8859-5.txt
diff --git a/t/t8005/iso8859-5.txt b/t/t8005/iso8859-5.txt
deleted file mode 100644
index 2e4b80c8df4da30722561049c46cca778e49cd2f..0000000000000000000000000000000000000000
GIT binary patch
literal 0
HcmV?d00001
literal 74
zcmeYa_P4MwwTw57_jB}hwN=`2>B3!w{Z}77xOeHsbA^L9uG|B%l(;<M%6x;}ZIupP
Zefa3!rF&Nu9^Sim@#WRKH?Asi0RTCvCqV!J
--
1.6.4.1
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* [PATCH] Majorly simplify the definition of scissors line
From: しらいし ななこ @ 2009-08-29 7:17 UTC (permalink / raw)
To: git; +Cc: Nicolas Sebrecht, Junio C Hamano
The definition of scissors line was "a line that mainly consists of
scissors and perforation". While it is easy to explain to new people,
this does not exactly define where the line between "mainly consists
of" and "contains some amount of" lies.
Make the definition more strict and allow only lines that begin with
a '-- >8 --' (or its left-handed equivalent '-- 8< --'), which is
equally easy to explain to new people. More important, the rule is
much shorter and more precise, so it is easier to remember.
This pattern also is how Nicolas Sebrecht initially thought what the
definition was, without reading what Junio's code really did, so we
have an empirical evidence that this matches at least one newcomer's
intuition.
Signed-off-by: しらいし ななこ <nanako3@lavabit.com>
---
Documentation/git-mailinfo.txt | 4 +-
builtin-mailinfo.c | 48 +++------------------------------------
t/t5100/msg0014 | 4 +-
t/t5100/sample.mbox | 4 +-
4 files changed, 10 insertions(+), 50 deletions(-)
diff --git a/Documentation/git-mailinfo.txt b/Documentation/git-mailinfo.txt
index 71b93ad..1c2c414 100644
--- a/Documentation/git-mailinfo.txt
+++ b/Documentation/git-mailinfo.txt
@@ -56,8 +56,8 @@ conversion, even with this flag.
--scissors::
Remove everything in body before a scissors line. A line that
- mainly consists of scissors (either ">8" or "8<") and perforation
- (dash "-") marks is called a scissors line, and is used to request
+ begins with "-- >8 --" or "-- 8< --" is called a scissors line,
+ and is used to request
the reader to cut the message at that line. If such a line
appears in the body of the message before the patch, everything
before it (including the scissors line itself) is ignored when
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 508bdf0..1bbad4e 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -722,52 +722,12 @@ static inline int patchbreak(const struct strbuf *line)
static int is_scissors_line(const struct strbuf *line)
{
- size_t i, len = line->len;
- int scissors = 0, gap = 0;
- int first_nonblank = -1;
- int last_nonblank = 0, visible, perforation = 0, in_perforation = 0;
const char *buf = line->buf;
+ size_t len = line->len;
- for (i = 0; i < len; i++) {
- if (isspace(buf[i])) {
- if (in_perforation) {
- perforation++;
- gap++;
- }
- continue;
- }
- last_nonblank = i;
- if (first_nonblank < 0)
- first_nonblank = i;
- if (buf[i] == '-') {
- in_perforation = 1;
- perforation++;
- continue;
- }
- if (i + 1 < len &&
- (!memcmp(buf + i, ">8", 2) || !memcmp(buf + i, "8<", 2))) {
- in_perforation = 1;
- perforation += 2;
- scissors += 2;
- i++;
- continue;
- }
- in_perforation = 0;
- }
-
- /*
- * The mark must be at least 8 bytes long (e.g. "-- >8 --").
- * Even though there can be arbitrary cruft on the same line
- * (e.g. "cut here"), in order to avoid misidentification, the
- * perforation must occupy more than a third of the visible
- * width of the line, and dashes and scissors must occupy more
- * than half of the perforation.
- */
-
- visible = last_nonblank - first_nonblank + 1;
- return (scissors && 8 <= visible &&
- visible < perforation * 3 &&
- gap * 2 < perforation);
+ if (len < 8)
+ return 0;
+ return (!memcmp("-- >8 --", buf, 8) || !memcmp("-- 8< --", buf, 8));
}
static int handle_commit_msg(struct strbuf *line)
diff --git a/t/t5100/msg0014 b/t/t5100/msg0014
index 62e5cd2..187ff57 100644
--- a/t/t5100/msg0014
+++ b/t/t5100/msg0014
@@ -6,8 +6,8 @@ Subject: [PATCH] BLAH TWO
And then we will see the scissors.
- This line is not a scissors mark -- >8 -- but talks about it.
- - - >8 - - please remove everything above this line - - >8 - -
+ This is not a scissors line -- >8 -- but talks about it.
+-- >8 -- please remove everything above this line -- >8 --
Subject: [PATCH] Teach mailinfo to ignore everything before -- >8 -- mark
From: Junio C Hamano <gitster@pobox.com>
diff --git a/t/t5100/sample.mbox b/t/t5100/sample.mbox
index 13fa4ae..563f713 100644
--- a/t/t5100/sample.mbox
+++ b/t/t5100/sample.mbox
@@ -576,8 +576,8 @@ Subject: [PATCH] BLAH TWO
And then we will see the scissors.
- This line is not a scissors mark -- >8 -- but talks about it.
- - - >8 - - please remove everything above this line - - >8 - -
+ This is not a scissors line -- >8 -- but talks about it.
+-- >8 -- please remove everything above this line -- >8 --
Subject: [PATCH] Teach mailinfo to ignore everything before -- >8 -- mark
From: Junio C Hamano <gitster@pobox.com>
--
1.6.4.1
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply related
* Re: [PATCH] Remove unused t/t8005/iso8859-5.txt file
From: Junio C Hamano @ 2009-08-29 7:48 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20090829161637.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> This file is no longer used since commit 54bc13c.
Hmm, the patch is grossly encoding damaged, so I'll hand apply.
Out of curiosity, how did you find this?
^ permalink raw reply
* Re: git-bz: command line integration for bugzilla
From: Jakub Narebski @ 2009-08-29 8:07 UTC (permalink / raw)
To: Owen Taylor; +Cc: git
In-Reply-To: <1251512664.666.349.camel@localhost.localdomain>
Owen Taylor <otaylor@redhat.com> writes:
> Was filling out the Git user's survey today, and noticed that my git-bz
> tool wasn't on the long list of "Git interfaces, implementations,
> frontends and tools"
Well, you can always add it in "Other (please specify)" in survey
> - but then again, I've never really advertised it
> beyond GNOME IRC. So, I was reminded to mention it here...
Could you please add (short) information about this tool to Git Wiki:
http://git.or.cz/gitwiki/InterfacesFrontendsAndTools
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Remove unused t/t8005/iso8859-5.txt file
From: Nanako Shiraishi @ 2009-08-29 8:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy6p3giwf.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> Out of curiosity, how did you find this?
Soon after you posted your original in http://thread.gmane.org/gmane.comp.version-control.git/121881, I applied it to my tree, and I have been running 'git pull --rebase' for ever. I noticed that rebase didn't remove the commit, even after your 54bc13c.
Today I found that the rebased patch only removed that file. The real question is how you lost the deletion of the file when you applied. What happened?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* [PATCH] update-server-info: make builtin, use parseopt
From: René Scharfe @ 2009-08-29 9:04 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
Convert git update-server-info to a built-in command and use parseopt.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
Makefile | 2 +-
builtin-update-server-info.c | 25 +++++++++++++++++++++++++
builtin.h | 1 +
git.c | 1 +
update-server-info.c | 28 ----------------------------
5 files changed, 28 insertions(+), 29 deletions(-)
create mode 100644 builtin-update-server-info.c
delete mode 100644 update-server-info.c
diff --git a/Makefile b/Makefile
index d842e52..a614347 100644
--- a/Makefile
+++ b/Makefile
@@ -357,7 +357,6 @@ PROGRAMS += git-patch-id$X
PROGRAMS += git-shell$X
PROGRAMS += git-show-index$X
PROGRAMS += git-unpack-file$X
-PROGRAMS += git-update-server-info$X
PROGRAMS += git-upload-pack$X
PROGRAMS += git-var$X
@@ -636,6 +635,7 @@ BUILTIN_OBJS += builtin-tar-tree.o
BUILTIN_OBJS += builtin-unpack-objects.o
BUILTIN_OBJS += builtin-update-index.o
BUILTIN_OBJS += builtin-update-ref.o
+BUILTIN_OBJS += builtin-update-server-info.o
BUILTIN_OBJS += builtin-upload-archive.o
BUILTIN_OBJS += builtin-verify-pack.o
BUILTIN_OBJS += builtin-verify-tag.o
diff --git a/builtin-update-server-info.c b/builtin-update-server-info.c
new file mode 100644
index 0000000..2b3fddc
--- /dev/null
+++ b/builtin-update-server-info.c
@@ -0,0 +1,25 @@
+#include "cache.h"
+#include "builtin.h"
+#include "parse-options.h"
+
+static const char * const update_server_info_usage[] = {
+ "git update-server-info [--force]",
+ NULL
+};
+
+int cmd_update_server_info(int argc, const char **argv, const char *prefix)
+{
+ int force = 0;
+ struct option options[] = {
+ OPT_BOOLEAN('f', "force", &force,
+ "update the info files from scratch"),
+ OPT_END()
+ };
+
+ argc = parse_options(argc, argv, prefix, options,
+ update_server_info_usage, 0);
+ if (argc > 0)
+ usage_with_options(update_server_info_usage, options);
+
+ return !!update_server_info(force);
+}
diff --git a/builtin.h b/builtin.h
index 51e4ba7..a2174dc 100644
--- a/builtin.h
+++ b/builtin.h
@@ -102,6 +102,7 @@ extern int cmd_tar_tree(int argc, const char **argv, const char *prefix);
extern int cmd_unpack_objects(int argc, const char **argv, const char *prefix);
extern int cmd_update_index(int argc, const char **argv, const char *prefix);
extern int cmd_update_ref(int argc, const char **argv, const char *prefix);
+extern int cmd_update_server_info(int argc, const char **argv, const char *prefix);
extern int cmd_upload_archive(int argc, const char **argv, const char *prefix);
extern int cmd_upload_tar(int argc, const char **argv, const char *prefix);
extern int cmd_verify_tag(int argc, const char **argv, const char *prefix);
diff --git a/git.c b/git.c
index 5da6c65..0b22595 100644
--- a/git.c
+++ b/git.c
@@ -359,6 +359,7 @@ static void handle_internal_command(int argc, const char **argv)
{ "unpack-objects", cmd_unpack_objects, RUN_SETUP },
{ "update-index", cmd_update_index, RUN_SETUP },
{ "update-ref", cmd_update_ref, RUN_SETUP },
+ { "update-server-info", cmd_update_server_info, RUN_SETUP },
{ "upload-archive", cmd_upload_archive },
{ "verify-tag", cmd_verify_tag, RUN_SETUP },
{ "version", cmd_version },
diff --git a/update-server-info.c b/update-server-info.c
deleted file mode 100644
index 7b38fd8..0000000
--- a/update-server-info.c
+++ /dev/null
@@ -1,28 +0,0 @@
-#include "cache.h"
-#include "exec_cmd.h"
-
-static const char update_server_info_usage[] =
-"git update-server-info [--force]";
-
-int main(int ac, char **av)
-{
- int i;
- int force = 0;
- for (i = 1; i < ac; i++) {
- if (av[i][0] == '-') {
- if (!strcmp("--force", av[i]) ||
- !strcmp("-f", av[i]))
- force = 1;
- else
- usage(update_server_info_usage);
- }
- }
- if (i != ac)
- usage(update_server_info_usage);
-
- git_extract_argv0_path(av[0]);
-
- setup_git_directory();
-
- return !!update_server_info(force);
-}
--
1.6.4.1
^ permalink raw reply related
* [PATCH] UI consistency: allow --force for where -f means force
From: René Scharfe @ 2009-08-29 9:05 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
git branch, checkout, clean, mv and tag all have an option -f to override
certain checks. This patch makes them accept the long option --force as
a synonym.
While we're at it, document that checkout support --quiet as synonym for
its short option -q.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
Documentation/git-branch.txt | 1 +
Documentation/git-checkout.txt | 2 ++
Documentation/git-clean.txt | 1 +
Documentation/git-mv.txt | 1 +
Documentation/git-tag.txt | 1 +
builtin-branch.c | 2 +-
builtin-checkout.c | 2 +-
builtin-clean.c | 2 +-
builtin-mv.c | 2 +-
builtin-tag.c | 2 +-
10 files changed, 11 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 9998887..aad71dc 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -76,6 +76,7 @@ OPTIONS
based sha1 expressions such as "<branchname>@\{yesterday}".
-f::
+--force::
Reset <branchname> to <startpoint> if <branchname> exists
already. Without `-f` 'git-branch' refuses to change an existing branch.
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index ad4b31e..b1314b5 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -45,9 +45,11 @@ file can be discarded to recreate the original conflicted merge result.
OPTIONS
-------
-q::
+--quiet::
Quiet, suppress feedback messages.
-f::
+--force::
When switching branches, proceed even if the index or the
working tree differs from HEAD. This is used to throw away
local changes.
diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index ae8938b..9d291bd 100644
--- a/Documentation/git-clean.txt
+++ b/Documentation/git-clean.txt
@@ -32,6 +32,7 @@ OPTIONS
if you really want to remove such a directory.
-f::
+--force::
If the git configuration specifies clean.requireForce as true,
'git-clean' will refuse to run unless given -f or -n.
diff --git a/Documentation/git-mv.txt b/Documentation/git-mv.txt
index 9c56602..bdcb585 100644
--- a/Documentation/git-mv.txt
+++ b/Documentation/git-mv.txt
@@ -28,6 +28,7 @@ committed.
OPTIONS
-------
-f::
+--force::
Force renaming or moving of a file even if the target exists
-k::
Skip move or rename actions which would lead to an error
diff --git a/Documentation/git-tag.txt b/Documentation/git-tag.txt
index 5113eae..299b04f 100644
--- a/Documentation/git-tag.txt
+++ b/Documentation/git-tag.txt
@@ -51,6 +51,7 @@ OPTIONS
Make a GPG-signed tag, using the given key
-f::
+--force::
Replace an existing tag with the given name (instead of failing)
-d::
diff --git a/builtin-branch.c b/builtin-branch.c
index 1a03d5f..9f57992 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -586,7 +586,7 @@ int cmd_branch(int argc, const char **argv, const char *prefix)
OPT_BIT('m', NULL, &rename, "move/rename a branch and its reflog", 1),
OPT_BIT('M', NULL, &rename, "move/rename a branch, even if target exists", 2),
OPT_BOOLEAN('l', NULL, &reflog, "create the branch's reflog"),
- OPT_BOOLEAN('f', NULL, &force_create, "force creation (when already exists)"),
+ OPT_BOOLEAN('f', "force", &force_create, "force creation (when already exists)"),
{
OPTION_CALLBACK, 0, "no-merged", &merge_filter_ref,
"commit", "print only not merged branches",
diff --git a/builtin-checkout.c b/builtin-checkout.c
index c6d6ac9..36e2116 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -584,7 +584,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
2),
OPT_SET_INT('3', "theirs", &opts.writeout_stage, "stage",
3),
- OPT_BOOLEAN('f', NULL, &opts.force, "force"),
+ OPT_BOOLEAN('f', "force", &opts.force, "force"),
OPT_BOOLEAN('m', "merge", &opts.merge, "merge"),
OPT_STRING(0, "conflict", &conflict_style, "style",
"conflict style (merge or diff3)"),
diff --git a/builtin-clean.c b/builtin-clean.c
index 05c763c..28cdcd0 100644
--- a/builtin-clean.c
+++ b/builtin-clean.c
@@ -41,7 +41,7 @@ int cmd_clean(int argc, const char **argv, const char *prefix)
struct option options[] = {
OPT__QUIET(&quiet),
OPT__DRY_RUN(&show_only),
- OPT_BOOLEAN('f', NULL, &force, "force"),
+ OPT_BOOLEAN('f', "force", &force, "force"),
OPT_BOOLEAN('d', NULL, &remove_directories,
"remove whole directories"),
OPT_BOOLEAN('x', NULL, &ignored, "remove ignored files, too"),
diff --git a/builtin-mv.c b/builtin-mv.c
index b592c36..1b20028 100644
--- a/builtin-mv.c
+++ b/builtin-mv.c
@@ -53,7 +53,7 @@ int cmd_mv(int argc, const char **argv, const char *prefix)
int verbose = 0, show_only = 0, force = 0, ignore_errors = 0;
struct option builtin_mv_options[] = {
OPT__DRY_RUN(&show_only),
- OPT_BOOLEAN('f', NULL, &force, "force move/rename even if target exists"),
+ OPT_BOOLEAN('f', "force", &force, "force move/rename even if target exists"),
OPT_BOOLEAN('k', NULL, &ignore_errors, "skip move/rename errors"),
OPT_END(),
};
diff --git a/builtin-tag.c b/builtin-tag.c
index a51a6d1..c479018 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -390,7 +390,7 @@ int cmd_tag(int argc, const char **argv, const char *prefix)
OPT_BOOLEAN('s', NULL, &sign, "annotated and GPG-signed tag"),
OPT_STRING('u', NULL, &keyid, "key-id",
"use another key to sign the tag"),
- OPT_BOOLEAN('f', NULL, &force, "replace the tag if exists"),
+ OPT_BOOLEAN('f', "force", &force, "replace the tag if exists"),
OPT_GROUP("Tag listing options"),
{
--
1.6.4.1
^ 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