* Re: Google Summer of Code 2009: GIT
From: Johannes Schindelin @ 2009-03-19 10:24 UTC (permalink / raw)
To: david; +Cc: saurabh gupta, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.10.0903190129110.4560@asgard.lang.hm>
Hi,
On Thu, 19 Mar 2009, david@lang.hm wrote:
> all three formats mentioned here (OOXML, ODF, SVG) are XML-based formats
> and a single flexible XML merge driver could potentially handle all
> three (as well as other formats). for that matter, the ODF specs cover
> multiple types of data, and I suspect that appropriate conflict markers
> for text could well end up being different than the ones for
> spreadsheets.
You are misunderstanding me.
The fact that all three are XML based has nothing to do with the _real_
goal of the project.
IOW a user trying to 3-way-merge ODF files could not care less if the
underlying technical details involve having an extra merge driver for XML
files or not.
The user cares about the ease of use, about the user interface. That is
what I want to focus on.
And if we end up with a beautiful XML merge driver at the end of the
summer that nobody uses, I will be not only a little disappointed.
So let's look at the _nature_ of the data at hand, i.e. text, marked-up
text, images (we could include UML, which is also XML-based, and where the
XML merge driver is as relevant for the user experience as for the
others), and how to make it _easy_ to resolve merge conflicts there.
Ciao,
Dscho
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: Johannes Schindelin @ 2009-03-19 10:19 UTC (permalink / raw)
To: Caleb Cushing; +Cc: saurabh gupta, david, Junio C Hamano, git
In-Reply-To: <81bfc67a0903182330q786ef01ai9148e41664a3471a@mail.gmail.com>
Hi,
On Thu, 19 Mar 2009, Caleb Cushing wrote:
> On Wed, Mar 18, 2009 at 7:16 PM, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
>
> > In my humble opinion, we should focus on the data types we want to be
> > able to support at the end of the summer first.
>
> my 2 cents don't support xml, support sgml start at the least common
> denominator and refine from there.
Sorry, by "data type" I tried to refer to the nature of the file. I
should have said "file type".
Ciao,
Dscho
^ permalink raw reply
* Re: Advice wanted to set up GIT repository manually sync'ed form SVN
From: Michael J Gruber @ 2009-03-19 10:16 UTC (permalink / raw)
To: Aaron Gray; +Cc: Git Mailing List
In-Reply-To: <79BA5EFC11BE4E06A78D39D06D1549AF@HPLAPTOP>
Aaron Gray venit, vidit, dixit 18.03.2009 21:46:
> Hi,
>
> I am a realitive GIT newbie, ie I have not used GIT on a project but have
> read quite a lot of documentation on it, over the last year or so.
>
> We are wanting to have a git and git-web repository that is synced to a main
> SVN repository, wh only want to read the SVN repository at this stage. I am
> planning on using git-svn raw, and do fetch'es by hand.
>
> Is there any advice that I should know at this point before proceeding ?
Read-only access should be mostly pain-free, unless the structure of the
svn repo is unfriendly. If it exists already and is large I'd suggest to
do a few test conversions with limited revision range first, adjust the
config, optionally set up an author map and then go live.
Michael
^ permalink raw reply
* Re: [PATCH] Documentation: reworded the "Description" section of git-bisect.txt.
From: Michael J Gruber @ 2009-03-19 10:12 UTC (permalink / raw)
To: David J. Mellor; +Cc: gitster, git
In-Reply-To: <1237446012-4533-1-git-send-email-dmellor@whistlingcat.com>
David J. Mellor venit, vidit, dixit 19.03.2009 08:00:
> Added fixes missing from 2364259.
>
> Signed-off-by: David J. Mellor <dmellor@whistlingcat.com>
> ---
> Documentation/git-bisect.txt | 17 +++++++++--------
> 1 files changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
> index 51d06c1..1a4a527 100644
> --- a/Documentation/git-bisect.txt
> +++ b/Documentation/git-bisect.txt
> @@ -114,21 +114,22 @@ $ git bisect view --stat
> Bisect log and bisect replay
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>
> -The good/bad input is logged, and:
> +After having marked revisions as good or bad, then:
>
> ------------
> $ git bisect log
> ------------
>
> -shows what you have done so far. You can truncate its output somewhere
> -and save it in a file, and run:
> +shows what you have done so far. If you discover that you made a mistake
> +in specifying the status of a revision, you can save the output of this
> +command to a file, edit it to remove the incorrect entries, and then issue
> +the following commands to return to a corrected state:
>
I guess his tells me that I should not have taken the following
(http://article.gmane.org/gmane.comp.version-control.git/113568) literally:
David J. Mellor venit, vidit, dixit 18.03.2009 03:54:
> On 03/17/2009 02:18 AM, Michael J Gruber wrote:
>> One minor reoccurring issue is the following type of construct:
>>
>> ###
>> The good/bad input is logged, and:
>>
>> ------------
>> $ git bisect log
>> ------------
>>
>> shows what you have done so far.
>> ###
>>
>> The first line is not a complete sentence.
>
> I agree. I will send a revised patch (patch 2 in this sequence) that
> corrects this.
Again, I think the patch improves the documentation nicely, I just don't
think that construct is helpful.
> ------------
> +$ git bisect reset
> $ git bisect replay that-file
> ------------
>
> -if you find later that you made a mistake specifying revisions as good/bad.
> -
> Avoiding testing a commit
> ~~~~~~~~~~~~~~~~~~~~~~~~~
>
> @@ -141,7 +142,7 @@ want to find a nearby commit and try that instead.
> For example:
>
> ------------
> -$ git bisect good/bad # previous round was good/bad.
> +$ git bisect good/bad # previous round was good or bad.
> Bisecting: 337 revisions left to test after this
> $ git bisect visualize # oops, that is uninteresting.
> $ git reset --hard HEAD~3 # try 3 revisions before what
> @@ -149,7 +150,7 @@ $ git reset --hard HEAD~3 # try 3 revisions before what
> ------------
>
> Then compile and test the chosen revision. Afterwards the revision
> -is marked as good/bad in the usual manner.
> +is marked as good or bad in the usual manner.
>
> Bisect skip
> ~~~~~~~~~~~~
> @@ -240,7 +241,7 @@ before compiling, run the real test, and afterwards decide if the
> revision (possibly with the needed patch) passed the test and then
> rewind the tree to the pristine state. Finally the script should exit
> with the status of the real test to let the "git bisect run" command loop
> -to determine the eventual outcome of the bisect session.
> +determine the eventual outcome of the bisect session.
>
> EXAMPLES
> --------
^ permalink raw reply
* Re: [PATCH JGIT] Method invokes inefficient Number constructor; use static valueOf instead
From: Ferry Huberts (Pelagic) @ 2009-03-19 9:45 UTC (permalink / raw)
To: Yann Simon; +Cc: Robin Rosenberg, Shawn O. Pearce, git
In-Reply-To: <49C20D13.2050908@gmail.com>
Yann Simon wrote:
> From FindBugs:
+1
also, junit would be another +1 AFAIC :-)
^ permalink raw reply
* [PATCH JGIT] Inefficient use of keySet iterator instead of entrySet iterator
From: Yann Simon @ 2009-03-19 9:17 UTC (permalink / raw)
To: Robin Rosenberg, Shawn O. Pearce; +Cc: git
>From FindBugs:
This method accesses the value of a Map entry, using a key that
was retrieved from a keySet iterator. It is more efficient to use
an iterator on the entrySet of the map, to avoid the Map.get(key)
lookup.
Signed-off-by: Yann Simon <yann.simon.fr@gmail.com>
---
.../src/org/spearce/jgit/lib/ObjectIdMap.java | 5 +++--
.../src/org/spearce/jgit/transport/AmazonS3.java | 5 +++--
2 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/ObjectIdMap.java b/org.spearce.jgit/src/org/spearce/jgit/lib/ObjectIdMap.java
index d3c7f1d..10feaf9 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/ObjectIdMap.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/ObjectIdMap.java
@@ -183,8 +183,9 @@ public V put(ObjectId key, V value) {
}
public void putAll(Map<? extends ObjectId, ? extends V> arg0) {
- for (ObjectId k : arg0.keySet()) {
- V v=arg0.get(k);
+ for (Map.Entry<? extends ObjectId, ? extends V> entry : arg0.entrySet()) {
+ ObjectId k = entry.getKey();
+ V v=entry.getValue();
put(k,v);
}
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/AmazonS3.java b/org.spearce.jgit/src/org/spearce/jgit/transport/AmazonS3.java
index 59337f8..3d8bdca 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/AmazonS3.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/AmazonS3.java
@@ -572,9 +572,10 @@ private HttpURLConnection open(final String method, final String bucket,
private void authorize(final HttpURLConnection c) throws IOException {
final Map<String, List<String>> reqHdr = c.getRequestProperties();
final SortedMap<String, String> sigHdr = new TreeMap<String, String>();
- for (final String hdr : reqHdr.keySet()) {
+ for (final Map.Entry<String, List<String>> entry : reqHdr.entrySet()) {
+ final String hdr = entry.getKey();
if (isSignedHeader(hdr))
- sigHdr.put(hdr.toLowerCase(), toCleanString(reqHdr.get(hdr)));
+ sigHdr.put(hdr.toLowerCase(), toCleanString(entry.getValue()));
}
final StringBuilder s = new StringBuilder();
--
1.6.1.2
^ permalink raw reply related
* [PATCH JGIT 4/5] Method fails to close stream
From: Yann Simon @ 2009-03-19 9:16 UTC (permalink / raw)
To: Robin Rosenberg, Shawn O. Pearce; +Cc: git
The stream was only closed in case of an error.
Use a finally block instead to ensure that the
stream is closed.
Signed-off-by: Yann Simon <yann.simon.fr@gmail.com>
---
.../src/org/spearce/jgit/lib/Repository.java | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
index 8132e27..cfd92b8 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/Repository.java
@@ -152,7 +152,7 @@ public Repository(final File d) throws IOException {
for (String alt=ar.readLine(); alt!=null; alt=ar.readLine()) {
readObjectsDirs(FS.resolve(objectsDir, alt), ret);
}
- } catch (Exception e) {
+ } finally {
ar.close();
}
}
--
1.6.1.2
^ permalink raw reply related
* [PATCH JGIT] Method invokes inefficient new String(String) constructor
From: Yann Simon @ 2009-03-19 9:15 UTC (permalink / raw)
To: Robin Rosenberg, Shawn O. Pearce; +Cc: git
>From FindBugs:
Using the java.lang.String(String) constructor wastes memory because
the object so constructed will be functionally indistinguishable from
the String passed as a parameter. Just use the argument String directly.
Signed-off-by: Yann Simon <yann.simon.fr@gmail.com>
---
.../src/org/spearce/jgit/lib/RefDatabase.java | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java b/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java
index 87f26bf..49da538 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/lib/RefDatabase.java
@@ -447,7 +447,7 @@ private synchronized void refreshPackedRefs() {
final int sp = p.indexOf(' ');
final ObjectId id = ObjectId.fromString(p.substring(0, sp));
- final String name = new String(p.substring(sp + 1));
+ final String name = p.substring(sp + 1);
last = new Ref(Ref.Storage.PACKED, name, name, id);
newPackedRefs.put(last.getName(), last);
}
--
1.6.1.2
^ permalink raw reply related
* [PATCH JGIT] Method invokes inefficient Number constructor; use static valueOf instead
From: Yann Simon @ 2009-03-19 9:14 UTC (permalink / raw)
To: Robin Rosenberg, Shawn O. Pearce; +Cc: git
>From FindBugs:
Using new Integer(int) is guaranteed to always result in a new object
whereas Integer.valueOf(int) allows caching of values to be done by the
compiler, class library, or JVM. Using of cached values avoids object
allocation and the code will be faster.
Values between -128 and 127 are guaranteed to have corresponding cached
instances and using valueOf is approximately 3.5 times faster than using
constructor. For values outside the constant range the performance of
both styles is the same.
Signed-off-by: Yann Simon <yann.simon.fr@gmail.com>
---
.../jgit/errors/NoClosingBracketException.java | 4 ++--
.../src/org/spearce/jgit/transport/IndexPack.java | 6 +++---
2 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/org.spearce.jgit/src/org/spearce/jgit/errors/NoClosingBracketException.java b/org.spearce.jgit/src/org/spearce/jgit/errors/NoClosingBracketException.java
index 8fe9ab1..b325b45 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/errors/NoClosingBracketException.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/errors/NoClosingBracketException.java
@@ -64,7 +64,7 @@ super(createMessage(indexOfOpeningBracket, openingBracket,
private static String createMessage(final int indexOfOpeningBracket,
final String openingBracket, final String closingBracket) {
return String.format("No closing %s found for %s at index %s.",
- closingBracket, openingBracket, new Integer(
- indexOfOpeningBracket));
+ closingBracket, openingBracket,
+ Integer.valueOf(indexOfOpeningBracket));
}
}
diff --git a/org.spearce.jgit/src/org/spearce/jgit/transport/IndexPack.java b/org.spearce.jgit/src/org/spearce/jgit/transport/IndexPack.java
index e0e4855..04ef59d 100644
--- a/org.spearce.jgit/src/org/spearce/jgit/transport/IndexPack.java
+++ b/org.spearce.jgit/src/org/spearce/jgit/transport/IndexPack.java
@@ -383,7 +383,7 @@ private void resolveDeltas(final ProgressMonitor progress)
private void resolveDeltas(final PackedObjectInfo oe) throws IOException {
final int oldCRC = oe.getCRC();
if (baseById.containsKey(oe)
- || baseByPos.containsKey(new Long(oe.getOffset())))
+ || baseByPos.containsKey(Long.valueOf(oe.getOffset())))
resolveDeltas(oe.getOffset(), oldCRC, Constants.OBJ_BAD, null, oe);
}
@@ -448,7 +448,7 @@ private void resolveDeltas(final long pos, final int oldCRC, int type,
private void resolveChildDeltas(final long pos, int type, byte[] data,
PackedObjectInfo oe) throws IOException {
final ArrayList<UnresolvedDelta> a = baseById.remove(oe);
- final ArrayList<UnresolvedDelta> b = baseByPos.remove(new Long(pos));
+ final ArrayList<UnresolvedDelta> b = baseByPos.remove(Long.valueOf(pos));
int ai = 0, bi = 0;
if (a != null && b != null) {
while (ai < a.size() && bi < b.size()) {
@@ -679,7 +679,7 @@ private void indexOneObject() throws IOException {
ofs <<= 7;
ofs += (c & 127);
}
- final Long base = new Long(pos - ofs);
+ final Long base = Long.valueOf(pos - ofs);
ArrayList<UnresolvedDelta> r = baseByPos.get(base);
if (r == null) {
r = new ArrayList<UnresolvedDelta>(8);
--
1.6.1.2
^ permalink raw reply related
* [PATCH 2/2] gitk: provide a 32x32 window icon based on the git logo
From: Stephen Boyd @ 2009-03-19 8:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Giuseppe Bilotta
In-Reply-To: <cover.1237451887.git.bebarino@gmail.com>
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
gitk | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/gitk b/gitk
index cfbb699..5a09eca 100755
--- a/gitk
+++ b/gitk
@@ -10901,7 +10901,10 @@ catch {
gitlogo copy gitlogoplus -to 11 9
image delete gitlogoplus
- wm iconphoto . -default gitlogo
+ image create photo gitlogo32 -width 32 -height 32
+ gitlogo32 copy gitlogo -zoom 2 2
+
+ wm iconphoto . -default gitlogo gitlogo32
}
# wait for the window to become visible
tkwait visibility .
--
1.6.2
^ permalink raw reply related
* [PATCH 1/2] gitk: try to provide a window icon
From: Stephen Boyd @ 2009-03-19 8:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Giuseppe Bilotta
In-Reply-To: <cover.1237451887.git.bebarino@gmail.com>
From: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Try to set up a 16x16 Tk photo image (based on the git logo) and use it
as window icon. Wrap the code in a catch because it may fail in earlier
Tcl/Tk 8.4 releases that don't provide 'wm iconphoto'.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
gitk | 20 ++++++++++++++++++++
1 files changed, 20 insertions(+), 0 deletions(-)
diff --git a/gitk b/gitk
index 1773ae6..cfbb699 100755
--- a/gitk
+++ b/gitk
@@ -10883,6 +10883,26 @@ set lserial 0
set isworktree [expr {[exec git rev-parse --is-inside-work-tree] == "true"}]
setcoords
makewindow
+catch {
+ image create photo gitlogo -width 16 -height 16
+
+ image create photo gitlogominus -width 4 -height 2
+ gitlogominus put #C00000 -to 0 0 4 2
+ gitlogo copy gitlogominus -to 1 5
+ gitlogo copy gitlogominus -to 6 5
+ gitlogo copy gitlogominus -to 11 5
+ image delete gitlogominus
+
+ image create photo gitlogoplus -width 4 -height 4
+ gitlogoplus put #008000 -to 1 0 3 4
+ gitlogoplus put #008000 -to 0 1 4 3
+ gitlogo copy gitlogoplus -to 1 9
+ gitlogo copy gitlogoplus -to 6 9
+ gitlogo copy gitlogoplus -to 11 9
+ image delete gitlogoplus
+
+ wm iconphoto . -default gitlogo
+}
# wait for the window to become visible
tkwait visibility .
wm title . "[file tail $argv0]: [file tail [pwd]]"
--
1.6.2
^ permalink raw reply related
* [PATCH 0/2] gitk window icons
From: Stephen Boyd @ 2009-03-19 8:54 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Giuseppe Bilotta
These two patches set the git logo, three red minus signs and three green plus
signs below on a white background, as the window icon for gitk.
I found this first patch by Giuseppe posted to the mailing list a couple months
ago. I've simply added a 32x32 icon in the second patch so that window managers
can provide a slightly better looking icon when they need a bigger icon
(ALT-TAB for example).
This logo is different than the logo used by git-gui. Do we want to use that
logo instead?
Giuseppe Bilotta (1):
gitk: try to provide a window icon
Stephen Boyd (1):
gitk: provide a 32x32 window icon based on the git logo
gitk | 23 +++++++++++++++++++++++
1 files changed, 23 insertions(+), 0 deletions(-)
^ permalink raw reply
* Re: Google Summer of Code 2009: GIT
From: david @ 2009-03-19 8:37 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: saurabh gupta, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0903190141300.10279@pacific.mpi-cbg.de>
On Thu, 19 Mar 2009, Johannes Schindelin wrote:
> On Wed, 18 Mar 2009, david@lang.hm wrote:
>
>> On Thu, 19 Mar 2009, Johannes Schindelin wrote:
>>
>>>
>>> In my humble opinion, we should focus on the data types we want to be
>>> able to support at the end of the summer first.
>>>
>>> For example, if we decide that OOXML is a must (as it is a proper
>>> standard, and many people will benefit from it), we will most likely
>>> end up in having to write a merge _driver_ (to handle those .zip
>>> files), _and_ a merge _helper_, although we can avoid writing our own
>>> GUI, as we can create an OOXML that has its own version of conflict
>>> markers.
>>
>> do you mean OOXML (the microsoft format) or ODF (the open office
>> format)?
>
> Oops.
>
> EOVERLOAD
it happens.
>>> If we decide that SVG is something we want to support by the end of
>>> the summer, then we can probably avoid writing a merge _driver_, as
>>> plain text is handled reasonably well in Git. OTOH it could turn out
>>> that there are _real_ conflicts in overlapping tag ids, and it would
>>> still be easier to write a merge driver, too.
>>>
>>> IOW the details are not as important as
>>>
>>> - knowing what data types we want to support _at the least_, and what
>>> data types we keep for the free skate,
>>>
>>> - a clear picture of the user interface we want to be able to provide,
>>>
>>> - a timeline (weekly milestones should be fine, I guess) what should
>>> be achieved when, and
>>>
>>> - being flexible in how to support that (IOW if a merge driver appears
>>> unnecessary first, but necessary later, we should be able to fit
>>> that into both the design and the timeline).
>>
>> it's up to the student, but I suspect that the best approach would be to
>> start with defining a merge driver to handle XML (with a minimum set of
>> capabilities, and additional optional ones), and go from there.
>
> Well, the thing is: if the student decides to have a go at an XML driver
> first and foremost, then I'll just flatly refuse to mentor that. Because
> I sincerely believe that this project is best designed from top to bottom,
> not the other way round.
>
> After all, the project is based on a user's request, not just a
> playthingie for an XML enthusiast (if such a thing exists).
all three formats mentioned here (OOXML, ODF, SVG) are XML-based formats
and a single flexible XML merge driver could potentially handle all three
(as well as other formats). for that matter, the ODF specs cover multiple
types of data, and I suspect that appropriate conflict markers for text
could well end up being different than the ones for spreadsheets.
that's not a 'plaything for an XML entusiast', it's making the tool
slightly more general than it would need to be for any one of these
formats to let it handle all of them.
but I'm not a mentor or a student, just an interested user.
David Lang
^ permalink raw reply
* submodules for different deployment directories?
From: Shaun Cutts @ 2009-03-19 8:33 UTC (permalink / raw)
To: git
Hello,
We are currently migrating from svn....
We have a growing project that is deployed differently in various
places. The deployment-specific stuff is in a subdirectory called
"deployment".
In svn, we used svn switch to point that subdirectory at a different
tag. Then "update" on the overall tree left alone the switched parts
at the various different installations. We could "push" changes in any
overall copy of the project and the differences between the switched
subdirectories would be immaterial.
It would seem (to me at least) that the equivalent functionality is
provided by "submodule" in git.
Accordingly I started a separate project with different branches
corresponding to the different deployment models.
I added this a submodule to the main project. In fact, we are thinking
of organizing some other things that differ by install this way, so I
made the actual directory a subdirectory of the "deployment" project,
which I "submodule added" to the various installations as a submodule
off the root repository, then used "ln -s" to link that subdirectory
into the appropriate place in the overall tree. (Is this a mistake?)
However, I'm not sure its working right. It seems that the various
overall repositories differ, even if only really the submodule's
branch differs. Also a diff comes up with lots of differences between
the submodules's trees. (Aside: where is the branch of the submodule
written down in the overall module -- if you add with -b... is this
just "transient info"?) But I thought that the idea of submodules were
that they are opaque?
I would enjoy help figuring out what is going on. I would be most
grateful, however, to learn how I'm *supposed* to do in this situation.
-- Shaun Cutts
----------------
Shaun Cutts
Partner
Entropy Capital, LLC
scutts@entropycap.com
^ permalink raw reply
* [PATCH] difftool: move 'git-difftool' out of contrib
From: David Aguilar @ 2009-03-19 8:25 UTC (permalink / raw)
To: gitster; +Cc: git, David Aguilar
This prepares 'git-difftool' and its documentation for
mainstream use. The backup file feature was removed since
most users found it annoying. The reasoning is that it's
better to start out with less features from the get-go and
only add things as users ask for them.
Signed-off-by: David Aguilar <davvid@gmail.com>
---
Most of these documentation changes were done to make things
more consistent.
.gitignore | 2 +
Documentation/config.txt | 17 +++++++++
.../difftool => Documentation}/git-difftool.txt | 35 +++++++------------
Makefile | 2 +
.../git-difftool-helper => git-difftool-helper.sh | 34 +------------------
contrib/difftool/git-difftool => git-difftool.perl | 0
6 files changed, 35 insertions(+), 55 deletions(-)
rename {contrib/difftool => Documentation}/git-difftool.txt (73%)
rename contrib/difftool/git-difftool-helper => git-difftool-helper.sh (86%)
rename contrib/difftool/git-difftool => git-difftool.perl (100%)
diff --git a/.gitignore b/.gitignore
index 1c57d4c..966c886 100644
--- a/.gitignore
+++ b/.gitignore
@@ -35,6 +35,8 @@ git-diff
git-diff-files
git-diff-index
git-diff-tree
+git-difftool
+git-difftool-helper
git-describe
git-fast-export
git-fast-import
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 12540b6..fda6c4c 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -663,6 +663,23 @@ diff.suppressBlankEmpty::
A boolean to inhibit the standard behavior of printing a space
before each empty output line. Defaults to false.
+diff.tool::
+ Controls which diff tool is used. `diff.tool` overrides
+ `merge.tool` when used by linkgit:git-difftool[1] and has
+ the same valid values as `merge.tool`.
+
+difftool.<tool>.path::
+ Override the path for the given tool. This is useful in case
+ your tool is not in the PATH.
+
+difftool.<tool>.cmd::
+ Specify the command to invoke the specified diff tool.
+ The specified command is evaluated in shell with the following
+ variables available: 'LOCAL' is set to the name of the temporary
+ file containing the contents of the diff pre-image and 'REMOTE'
+ is set to the name of the temporary file containing the contents
+ of the diff post-image.
+
diff.wordRegex::
A POSIX Extended Regular Expression used to determine what is a "word"
when performing word-by-word difference calculations. Character
diff --git a/contrib/difftool/git-difftool.txt b/Documentation/git-difftool.txt
similarity index 73%
rename from contrib/difftool/git-difftool.txt
rename to Documentation/git-difftool.txt
index 2b7bc03..5ae02f8 100644
--- a/contrib/difftool/git-difftool.txt
+++ b/Documentation/git-difftool.txt
@@ -3,35 +3,31 @@ git-difftool(1)
NAME
----
-git-difftool - compare changes using common merge tools
+git-difftool - Show changes using common diff tools
SYNOPSIS
--------
-'git difftool' [--tool=<tool>] [--no-prompt] ['git diff' options]
+'git difftool' [--tool=<tool>] [--no-prompt] [<'git diff' options>]
DESCRIPTION
-----------
'git-difftool' is a git command that allows you to compare and edit files
-between revisions using common merge tools. At its most basic level,
-'git-difftool' does what 'git-mergetool' does but its use is for non-merge
-situations such as when preparing commits or comparing changes against
-the index.
-
-'git difftool' is a frontend to 'git diff' and accepts the same
-arguments and options.
-
-See linkgit:git-diff[1] for the full list of supported options.
+between revisions using common diff tools. 'git difftool' is a frontend
+to 'git-diff' and accepts the same options and arguments.
OPTIONS
-------
+--no-prompt::
+ Do not prompt before launching a diff tool.
+
-t <tool>::
--tool=<tool>::
- Use the merge resolution program specified by <tool>.
+ Use the diff tool specified by <tool>.
Valid merge tools are:
kdiff3, kompare, tkdiff, meld, xxdiff, emerge,
vimdiff, gvimdiff, ecmerge, and opendiff
+
-If a merge resolution program is not specified, 'git-difftool'
+If a diff tool is not specified, 'git-difftool'
will use the configuration variable `diff.tool`. If the
configuration variable `diff.tool` is not set, 'git-difftool'
will pick a suitable default.
@@ -42,7 +38,7 @@ can configure the absolute path to kdiff3 by setting
`difftool.kdiff3.path`. Otherwise, 'git-difftool' assumes the
tool is available in PATH.
+
-Instead of running one of the known merge tool programs,
+Instead of running one of the known diff tools,
'git-difftool' can be customized to run an alternative program
by specifying the command line to invoke in a configuration
variable `difftool.<tool>.cmd`.
@@ -56,8 +52,7 @@ is set to the name of the temporary file containing the contents
of the diff post-image. `$BASE` is provided for compatibility
with custom merge tool commands and has the same value as `$LOCAL`.
---no-prompt::
- Do not prompt before launching a diff tool.
+See linkgit:git-diff[1] for the full list of supported options.
CONFIG VARIABLES
----------------
@@ -65,21 +60,17 @@ CONFIG VARIABLES
difftool equivalents have not been defined.
diff.tool::
- The default merge tool to use.
+ The default diff tool to use.
difftool.<tool>.path::
Override the path for the given tool. This is useful in case
your tool is not in the PATH.
difftool.<tool>.cmd::
- Specify the command to invoke the specified merge tool.
+ Specify the command to invoke the specified diff tool.
+
See the `--tool=<tool>` option above for more details.
-merge.keepBackup::
- The original, unedited file content can be saved to a file with
- a `.orig` extension. Defaults to `true` (i.e. keep the backup files).
-
SEE ALSO
--------
linkgit:git-diff[1]::
diff --git a/Makefile b/Makefile
index b96c2b3..cb99c5d 100644
--- a/Makefile
+++ b/Makefile
@@ -265,6 +265,7 @@ BASIC_LDFLAGS =
SCRIPT_SH += git-am.sh
SCRIPT_SH += git-bisect.sh
+SCRIPT_SH += git-difftool-helper.sh
SCRIPT_SH += git-filter-branch.sh
SCRIPT_SH += git-lost-found.sh
SCRIPT_SH += git-merge-octopus.sh
@@ -284,6 +285,7 @@ SCRIPT_SH += git-submodule.sh
SCRIPT_SH += git-web--browse.sh
SCRIPT_PERL += git-add--interactive.perl
+SCRIPT_PERL += git-difftool.perl
SCRIPT_PERL += git-archimport.perl
SCRIPT_PERL += git-cvsexportcommit.perl
SCRIPT_PERL += git-cvsimport.perl
diff --git a/contrib/difftool/git-difftool-helper b/git-difftool-helper.sh
similarity index 86%
rename from contrib/difftool/git-difftool-helper
rename to git-difftool-helper.sh
index 9c0a134..b91002b 100755
--- a/contrib/difftool/git-difftool-helper
+++ b/git-difftool-helper.sh
@@ -9,31 +9,7 @@
# Set GIT_DIFFTOOL_NO_PROMPT to bypass the per-file prompt.
should_prompt () {
- ! test -n "$GIT_DIFFTOOL_NO_PROMPT"
-}
-
-# Should we keep the backup .orig file?
-keep_backup_mode="$(git config --bool merge.keepBackup || echo true)"
-keep_backup () {
- test "$keep_backup_mode" = "true"
-}
-
-# This function manages the backup .orig file.
-# A backup $MERGED.orig file is created if changes are detected.
-cleanup_temp_files () {
- if test -n "$MERGED"; then
- if keep_backup && test "$MERGED" -nt "$BACKUP"; then
- test -f "$BACKUP" && mv -- "$BACKUP" "$MERGED.orig"
- else
- rm -f -- "$BACKUP"
- fi
- fi
-}
-
-# This is called when users Ctrl-C out of git-difftool-helper
-sigint_handler () {
- cleanup_temp_files
- exit 1
+ test -z "$GIT_DIFFTOOL_NO_PROMPT"
}
# This function prepares temporary files and launches the appropriate
@@ -47,12 +23,6 @@ launch_merge_tool () {
LOCAL="$2"
REMOTE="$3"
BASE="$1"
- ext="$$$(expr "$MERGED" : '.*\(\.[^/]*\)$')"
- BACKUP="$MERGED.BACKUP.$ext"
-
- # Create and ensure that we clean up $BACKUP
- test -f "$MERGED" && cp -- "$MERGED" "$BACKUP"
- trap sigint_handler INT
# $LOCAL and $REMOTE are temporary files so prompt
# the user with the real $MERGED name before launching $merge_tool.
@@ -124,8 +94,6 @@ launch_merge_tool () {
fi
;;
esac
-
- cleanup_temp_files
}
# Verifies that (difftool|mergetool).<tool>.cmd exists
diff --git a/contrib/difftool/git-difftool b/git-difftool.perl
similarity index 100%
rename from contrib/difftool/git-difftool
rename to git-difftool.perl
--
1.6.2.77.g8cc3f
^ permalink raw reply related
* submodules for different deployment directories?
From: Shaun Cutts @ 2009-03-19 8:01 UTC (permalink / raw)
To: git
Hello,
We are currently migrating from svn....
We have a growing project that is deployed differently in various
places. The deployment-specific stuff is in a subdirectory called
"deployment".
In svn, we used svn switch to point that subdirectory at a different
tag. Then "update" on the overall tree left alone the switched parts
at the various different installations. We could "push" changes in any
overall copy of the project and the differences between the switched
subdirectories would be immaterial.
It would seem (to me at least) that the equivalent functionality is
provided by "submodule" in git.
Accordingly I started a separate project with different branches
corresponding to the different deployment models.
I added this a submodule to the main project. In fact, we are thinking
of organizing some other things that differ by install this way, so I
made the actual directory a subdirectory of the "deployment" project,
which I "submodule added" to the various installations as a submodule
off the root repository, then used "ln -s" to link that subdirectory
into the appropriate place in the overall tree. (Is this a mistake?)
However, I'm not sure its working right. It seems that the various
overall repositories differ, even if only really the submodule's
branch differs. Also a diff comes up with lots of differences between
the submodules's trees. (Aside: where is the branch of the submodule
written down in the overall module -- if you add with -b... is this
just "transient info"?) But I thought that the idea of submodules were
that they are opaque?
I would enjoy help figuring out what is going on. I would be most
grateful, however, to learn how I'm *supposed* to do in this situation.
-- Shaun Cutts
^ permalink raw reply
* Re: [PATCH] git-gui: various French translation fixes
From: Sam Hocevar @ 2009-03-19 7:58 UTC (permalink / raw)
To: Christian Couder; +Cc: Git List, Alexandre Bourget
In-Reply-To: <200903190714.25211.chriscool@tuxfamily.org>
On Thu, Mar 19, 2009, Christian Couder wrote:
> > > #: git-gui.sh:2484 lib/index.tcl:410
> > > msgid "Revert Changes"
> > > -msgstr "Annuler les modifications (revert)"
> > > +msgstr "Révoquer les modifications"
> >
> > I am not sure that "Révoquer" is better than "Annuler".
>
> Perhaps "Inverser"?
I suggested "révoquer" because it was close enough to "revert" that
there was no need to specify "(revert)" in the translation itself.
It's what the French Wikipedia interface used to say to revert edits.
But I see they now use "défaire" (undo), so apparently they deemed
it inappropriate for some reason. I have no strong preference for
"Inverser" or even "Annuler", I just want it to be consistent and to get
rid of the "(revert)" at the end of this message.
Cheers,
--
Sam.
^ permalink raw reply
* Re: [PATCH 02/10] test suite: Use 'say' to say something instead of 'test_expect_success'
From: Johannes Sixt @ 2009-03-19 7:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0903182306020.10279@pacific.mpi-cbg.de>
Johannes Schindelin schrieb:
> Hi,
>
> On Wed, 18 Mar 2009, Johannes Sixt wrote:
>
>> Some tests report that some tests will be skipped. They used
>> 'test_exect_success' with a trivially successful test. Nowadays we have
>
> s/exect/expect/.
>
>> the helper function 'say' for this purpose.
>>
>> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
>
> I see that you exchanged one "say_color" by "say". What is the
> difference?
The color. It's a change towards consistency. I figured that the command
to use by the tests is "say", while "say_color" is an implementation
detail of test-lib.sh.
-- Hannes
^ permalink raw reply
* Re: [PATCH 05/10] test-lib: Simplify test counting.
From: Johannes Sixt @ 2009-03-19 7:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0903182331330.10279@pacific.mpi-cbg.de>
Johannes Schindelin schrieb:
> Hi,
>
> On Wed, 18 Mar 2009, Johannes Sixt wrote:
>
>> Since the test case counter was incremented very late, there were a few
>> users of the counter had to do their own incrementing. Now we increment it
>> early and simplify these users.
>>
>> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
>> ---
>> t/test-lib.sh | 10 +++-------
>> 1 files changed, 3 insertions(+), 7 deletions(-)
>
> Do you not need to adjust t4013 and t5515, too?
Yes, indeed. That makes sense.
-- Hannes
^ permalink raw reply
* Re: [PATCH 04/10] test-lib: Replace uses of $(expr ...) by POSIX shell features.
From: Johannes Sixt @ 2009-03-19 7:38 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0903182319180.10279@pacific.mpi-cbg.de>
Johannes Schindelin schrieb:
> Hi,
>
> On Wed, 18 Mar 2009, Johannes Sixt wrote:
>
>> In particular:
>>
>> - Test case counting can be achieved by arithmetic expansion.
>>
>> - The name of the test, e.g. t1234, can be computed with ${0%%} and ${0##}.
>>
>> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
>
> I guess this makes the tests less slow on Windows? Do you have numbers?
Actually, while reading through test-lib.sh I found those expr expressions
quite difficult to understand, and my primary intent was to make the code
more readable. Furthermore, as you can see in the hunk that touches
test_known_broken_{ok,failure}_ that the $(( )) construct is already in
use, so it's also a change to improve consistency.
The shorter runtime (primarily on Windows) is just a nice side effect,
although the gain probably vanishes in the noise.
> FWIW I run the tests on Windows with -j10 these days, and they take about
> 15 minutes on a quad core 3GHz machine (which I may use from time to time;
> the machine is not mine, otherwise it would run Linux).
Last time I tried -j<something> it bailed out early. I didn't try again
since then. Sequential tests finish in 30-40 minutes here, but I don't run
SVN tests.
-- Hannes
^ permalink raw reply
* Re: [PATCH 00/11] Test on Windows - prequel
From: Johannes Sixt @ 2009-03-19 7:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljr2bg9c.fsf@gitster.siamese.dyndns.org>
Junio C Hamano schrieb:
> Do you have an 11-patch series, or 10-patch series with a cover letter? I
> am wondering what happened to [PATCH 11/11].
It's a 10-patch series, I still haven't learnt to count, and this
format-patch and send-email business causes me head-aches again and again
and again... ;)
I first prepared an 11-patch series, wrote the coverletter, then changed
my mind and prepared a 10-patch series, copied the coverletter including
the Subject: line without updating it.
-- Hannes
^ permalink raw reply
* Re: t5505-remote fails on Windows
From: Johannes Sixt @ 2009-03-19 7:20 UTC (permalink / raw)
To: Jeff King; +Cc: Jay Soffian, Git Mailing List
In-Reply-To: <20090319044313.GA341@coredump.intra.peff.net>
Jeff King schrieb:
> I didn't look closely enough at your issue, which is one
> ref pushing to two different places. For that, the sort needs to take
> into account the util field, which holds the destination.
>
> The patch below probably fixes it, but as I can't actually reproduce
> here, it is largely untested.
Your patch fixes it. The following change to the test case would be a good
addition; it protects later tests from failures in earlier tests.
-- Hannes
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 5ec668d..13f32b8 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -160,7 +160,7 @@ cat > test/expect << EOF
master pushes to another (up to date)
EOF
-test_expect_success 'show' '
+test_expect_success 'more setup for show' '
(cd test &&
git config --add remote.origin.fetch refs/heads/master:refs/heads/upstream &&
git fetch &&
@@ -183,12 +183,20 @@ test_expect_success 'show' '
git config --add remote.origin.push refs/heads/master:refs/heads/upstream &&
git config --add remote.origin.push +refs/tags/lastbackup &&
git config --add remote.two.push +refs/heads/ahead:refs/heads/master &&
- git config --add remote.two.push refs/heads/master:refs/heads/another &&
+ git config --add remote.two.push refs/heads/master:refs/heads/another)
+'
+
+test_expect_success 'show' '
+ (cd test &&
git remote show origin two > output &&
- git branch -d rebase octopus &&
test_cmp expect output)
'
+test_expect_success 'more setup for show -n' '
+ (cd test &&
+ git branch -d rebase octopus)
+'
+
cat > test/expect << EOF
* remote origin
URL: $(pwd)/one
^ permalink raw reply related
* Re: [PATCH] git-gui: various French translation fixes
From: Christian Couder @ 2009-03-19 7:11 UTC (permalink / raw)
To: Mike Hommey; +Cc: Sam Hocevar, Git List, Alexandre Bourget
In-Reply-To: <20090319070246.GA6561@glandium.org>
Le jeudi 19 mars 2009, Mike Hommey a écrit :
> On Thu, Mar 19, 2009 at 06:09:25AM +0100, Christian Couder wrote:
> > Le mercredi 18 mars 2009, Sam Hocevar a écrit :
> > > #: lib/remote_branch_delete.tcl:47
> > > msgid "From Repository"
> > > @@ -2244,7 +2244,7 @@ msgid ""
> > > "One or more of the merge tests failed because you have not fetched
> > > the " "necessary commits. Try fetching from %s first."
> > > msgstr ""
> > > -"Une ou plusieurs des tests de fusion ont échoués parce que vous
> > > n'avez pas "
> > > +"Un ou plusieurs des tests de fusion ont échoué parce que vous
> > > n'avez pas "
> > > "récupéré les commits nécessaires. Essayez de récupéré à
> > > partir de %s d'abord."
> >
> > The last "récupéré" should be changed to "récupérer".
>
> No it shouldn't, it's "vous n'avez pas récupéré"
The last one is "Essayez de récupéré" but it should be "Essayez de
récupérer".
Regards,
Christian.
^ permalink raw reply
* Re: [PATCH] git-gui: various French translation fixes
From: Mike Hommey @ 2009-03-19 7:02 UTC (permalink / raw)
To: Christian Couder; +Cc: Sam Hocevar, Git List, Alexandre Bourget
In-Reply-To: <200903190609.25344.chriscool@tuxfamily.org>
On Thu, Mar 19, 2009 at 06:09:25AM +0100, Christian Couder wrote:
> Le mercredi 18 mars 2009, Sam Hocevar a écrit :
> > Mostly grammar, spelling and typography fixes, but also a few wording
> > enhancements here and there.
>
> It looks mostly good to me.
>
> > Signed-off-by: Sam Hocevar <sam@zoy.org>
> > ---
> > po/fr.po | 196
> > +++++++++++++++++++++++++++++++------------------------------- 1 files
> > changed, 98 insertions(+), 98 deletions(-)
> >
> > #: git-gui.sh:2484 lib/index.tcl:410
> > msgid "Revert Changes"
> > -msgstr "Annuler les modifications (revert)"
> > +msgstr "Révoquer les modifications"
>
> I am not sure that "Révoquer" is better than "Annuler".
>
> [...]
>
> > #: lib/index.tcl:326
> > msgid "Ready to commit."
> > @@ -1719,18 +1719,18 @@ msgstr "Ajout de %s"
> > #: lib/index.tcl:396
> > #, tcl-format
> > msgid "Revert changes in file %s?"
> > -msgstr "Annuler les modifications dans le fichier %s ? "
> > +msgstr "Révoquer les modifications dans le fichier %s ? "
> >
> > #: lib/index.tcl:398
> > #, tcl-format
> > msgid "Revert changes in these %i files?"
> > -msgstr "Annuler les modifications dans ces %i fichiers ?"
> > +msgstr "Révoquer les modifications dans ces %i fichiers ?"
> >
> > #: lib/index.tcl:406
> > msgid "Any unstaged changes will be permanently lost by the revert."
> > msgstr ""
> > "Toutes les modifications non-indexées seront définitivement perdues par
> > " -"l'annulation."
> > +"la révocation."
>
> Same thing for the 3 strings above.
I'm not sure i like "non-indexées" for "unstaged"
> [...]
>
> > #: lib/index.tcl:427
> > msgid "Reverting selected files"
> > -msgstr "Annuler modifications dans fichiers selectionnés"
> > +msgstr "Révocation en cours des fichiers selectionnés"
> >
> > #: lib/index.tcl:431
> > #, tcl-format
> > msgid "Reverting %s"
> > -msgstr "Annulation des modifications dans %s"
> > +msgstr "Révocation en cours de %s"
>
> Same thing above.
>
> > #: lib/remote_branch_delete.tcl:47
> > msgid "From Repository"
> > @@ -2244,7 +2244,7 @@ msgid ""
> > "One or more of the merge tests failed because you have not fetched the
> > " "necessary commits. Try fetching from %s first."
> > msgstr ""
> > -"Une ou plusieurs des tests de fusion ont échoués parce que vous n'avez
> > pas "
> > +"Un ou plusieurs des tests de fusion ont échoué parce que vous
> > n'avez pas "
> > "récupéré les commits nécessaires. Essayez de récupéré à
> > partir de %s d'abord."
>
> The last "récupéré" should be changed to "récupérer".
No it shouldn't, it's "vous n'avez pas récupéré"
Mike
^ permalink raw reply
* [PATCH] Documentation: reworded the "Description" section of git-bisect.txt.
From: David J. Mellor @ 2009-03-19 7:00 UTC (permalink / raw)
To: gitster; +Cc: git
Added fixes missing from 2364259.
Signed-off-by: David J. Mellor <dmellor@whistlingcat.com>
---
Documentation/git-bisect.txt | 17 +++++++++--------
1 files changed, 9 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-bisect.txt b/Documentation/git-bisect.txt
index 51d06c1..1a4a527 100644
--- a/Documentation/git-bisect.txt
+++ b/Documentation/git-bisect.txt
@@ -114,21 +114,22 @@ $ git bisect view --stat
Bisect log and bisect replay
~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-The good/bad input is logged, and:
+After having marked revisions as good or bad, then:
------------
$ git bisect log
------------
-shows what you have done so far. You can truncate its output somewhere
-and save it in a file, and run:
+shows what you have done so far. If you discover that you made a mistake
+in specifying the status of a revision, you can save the output of this
+command to a file, edit it to remove the incorrect entries, and then issue
+the following commands to return to a corrected state:
------------
+$ git bisect reset
$ git bisect replay that-file
------------
-if you find later that you made a mistake specifying revisions as good/bad.
-
Avoiding testing a commit
~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -141,7 +142,7 @@ want to find a nearby commit and try that instead.
For example:
------------
-$ git bisect good/bad # previous round was good/bad.
+$ git bisect good/bad # previous round was good or bad.
Bisecting: 337 revisions left to test after this
$ git bisect visualize # oops, that is uninteresting.
$ git reset --hard HEAD~3 # try 3 revisions before what
@@ -149,7 +150,7 @@ $ git reset --hard HEAD~3 # try 3 revisions before what
------------
Then compile and test the chosen revision. Afterwards the revision
-is marked as good/bad in the usual manner.
+is marked as good or bad in the usual manner.
Bisect skip
~~~~~~~~~~~~
@@ -240,7 +241,7 @@ before compiling, run the real test, and afterwards decide if the
revision (possibly with the needed patch) passed the test and then
rewind the tree to the pristine state. Finally the script should exit
with the status of the real test to let the "git bisect run" command loop
-to determine the eventual outcome of the bisect session.
+determine the eventual outcome of the bisect session.
EXAMPLES
--------
--
1.6.2.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