* Re: [PATCH] Make strbuf_cmp inline, constify its arguments and optimize it a bit
From: Alex Riesen @ 2007-10-08 18:51 UTC (permalink / raw)
To: Florian Weimer
Cc: Pierre Habouzit, Miles Bader, Wincent Colaiuta, David Kastrup,
Timo Hirvonen, git, Junio C Hamano
In-Reply-To: <82k5py6l6f.fsf@mid.bfk.de>
Florian Weimer, Mon, Oct 08, 2007 10:54:32 +0200:
> And "int len" in the first line of the function body should be
> "size_t len".
right. Missed that.
^ permalink raw reply
* Re: [PATCH 1/4] git-gui i18n: Add more words to glossary.
From: Christian Stimming @ 2007-10-08 19:43 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Johannes Schindelin, git
In-Reply-To: <20071007233937.GG2137@spearce.org>
Am Montag, 8. Oktober 2007 01:39 schrieb Shawn O. Pearce:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Sun, 7 Oct 2007, Shawn O. Pearce wrote:
> > > If you are sending a series like that and its all po translation stuff
> > > that is unlikely to need commenting on feel free to just dump it all
> > > out as a single mbox (`git format-patch --stdout`) and attach it to the
> > > email. Less chance of the MUA mangling the message.
> >
> > In this case, I suggest just pushing it to git-gui-i18n.git, maybe as a
> > temporary branch "for-shawn", and send a pull request. That's the best
> > way to ensure that nothing gets mangled.
>
> Yea, that's an even better option. :-)
All pushed to git-gui-i18n.git mob branch now. I hope you can easily merge
them over.
Maybe po/git-gui.pot should be updated by you on git-gui.git and (by Dscho?)
on git-gui-i18n.git as well.
In other news, according to http://marc.info/?l=git&m=119170887523610&w=2
(almost last paragraph) people are already recognizing the localized
versions, but this also means the translations have to be watched out for so
that they will get updated as completely as possible especially before the
next release.
http://wiki.gnucash.org/wiki/index.php?title=String_Freeze&oldid=2022 is an
example on how the gnucash project tried to communicate to its translators
how the special "string freeze" period (i.e. a few weeks before the release)
will be handled in order to get a finalized translation for the actual
release. I don't know how formal you want to put this, but at least *some*
period of string freeze would be very good. As for the German translation,
I'd prefer any period length greater than 10 days in order to verify a
complete translation...
Regards,
Christian
^ permalink raw reply
* Re: Trying to use git-filter-branch to compress history by removing large, obsolete binary files
From: J. Bruce Fields @ 2007-10-08 19:05 UTC (permalink / raw)
To: Theodore Tso
Cc: Johannes Sixt, Johannes Schindelin, Elijah Newren,
Frank Lichtenheld, git
In-Reply-To: <20071008163701.GA5868@thunk.org>
On Mon, Oct 08, 2007 at 12:37:01PM -0400, Theodore Tso wrote:
> I think what makes git-filter-branch different is that you can change
> a large amount of history with git-filter-branch, including large
> numbers of tags, etc. The reflog is quite sufficient to recover from
> a screwed up "git commit --amend". But I don't think the reflog is
> going to be sufficient given the kinds of changes that
> git-filter-branch can potentially do to your repository. Maybe
> default of --backup vs --no-backup could be changed via a config
> parameter, but I think the default is of backing up refs is a good
> think....
Yeah, it's clearly designed with rewriting a whole repo in mind.
It might also be handy, though, as a quick way to rewrite a single
branch. (E.g., "add 'Acked-by: Joe' to everything in 'for-upstream' not
in 'origin'", or "rename foo to bar in every commit in 'topic' not in
'origin'".).
I find the current defaults awkward for that case. Maybe it'd make
sense to treat the two cases differently.
> Perhaps a solution would be to add "git-filter-branch --cleanup" that
> that clears the reflog and wipes the backed up tags; perhaps first
> asking interactively if the user is really sure he/she wants to do
> this.
Maybe.
--b.
^ permalink raw reply
* Re: Merge problems with git-mingw
From: Lars Hjemli @ 2007-10-08 19:59 UTC (permalink / raw)
To: Peter Karlsson; +Cc: git, Johannes Sixt
In-Reply-To: <Pine.LNX.4.64.0710081555480.29570@ds9.cixit.se>
[Johannes CC'ed as the mingw.git maintainer]
On 10/8/07, Peter Karlsson <peter@softwolves.pp.se> wrote:
> $ git var GIT_COMMITTER_IDENT
> usage: git-var [-l | <variable>]
Does 'git var -l' work as expected? Also, could you try the latest
git-package provided by the cygwin installer? If CRLF-handling was
your problem, take a look at the description of core.autocrlf with
'git help config'.
[This does look like an issue with running mingw.git under Cygwin.
Johannes, is this even supposed to work?]
--
larsh
^ permalink raw reply
* Fix embarrassing "git log --follow" bug
From: Linus Torvalds @ 2007-10-08 20:42 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
It turns out that I completely broke "git log --follow" with my recent
patch to revision.c ("Fix revision log diff setup, avoid unnecessary diff
generation", commit b7bb760d5ed4881422673d32f869d140221d3564).
Why? Because --follow obviously requires the diff machinery to function,
exactly the same way pickaxe does.
So everybody is away right now, but considering that nobody even noticed
this bug, I don't think it matters. But for the record, here's the trivial
one-liner fix (well, two, since I also fixed the comment).
Because of the nature of the bug, if you ask for patches when following
(which is one of the things I normally do), the bug is hidden, because
then the request for diff output will automatically also enable the diffs
themselves.
So while "git log --follow <filename>" didn't work, adding a "-p"
magically made it work again even without this fix.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
revision.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/revision.c b/revision.c
index 5d294be..e76da0d 100644
--- a/revision.c
+++ b/revision.c
@@ -1241,8 +1241,8 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
if (revs->diffopt.output_format & ~DIFF_FORMAT_NO_OUTPUT)
revs->diff = 1;
- /* Pickaxe needs diffs */
- if (revs->diffopt.pickaxe)
+ /* Pickaxe and rename following needs diffs */
+ if (revs->diffopt.pickaxe || revs->diffopt.follow_renames)
revs->diff = 1;
if (revs->topo_order)
^ permalink raw reply related
* Clean up "git log" format with DIFF_FORMAT_NO_OUTPUT
From: Linus Torvalds @ 2007-10-08 20:46 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
In-Reply-To: <alpine.LFD.0.999.0710081337490.4964@woody.linux-foundation.org>
This fixes an unnecessary empty line that we add to the log message when
we generate diffs, but don't actually end up printing any due to having
DIFF_FORMAT_NO_OUTPUT set.
This can happen with pickaxe or with rename following. The reason is that
we normally add an empty line between the commit and the diff, but we do
that even for the case where we've then suppressed the actual printing of
the diff.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
---
log-tree.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 2319154..62edd34 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -304,7 +304,8 @@ int log_tree_diff_flush(struct rev_info *opt)
* output for readability.
*/
show_log(opt, opt->diffopt.msg_sep);
- if (opt->verbose_header &&
+ if ((opt->diffopt.output_format & ~DIFF_FORMAT_NO_OUTPUT) &&
+ opt->verbose_header &&
opt->commit_format != CMIT_FMT_ONELINE) {
int pch = DIFF_FORMAT_DIFFSTAT | DIFF_FORMAT_PATCH;
if ((pch & opt->diffopt.output_format) == pch)
^ permalink raw reply related
* Re: Clean up "git log" format with DIFF_FORMAT_NO_OUTPUT
From: Linus Torvalds @ 2007-10-08 20:55 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano
In-Reply-To: <alpine.LFD.0.999.0710081342530.4964@woody.linux-foundation.org>
On Mon, 8 Oct 2007, Linus Torvalds wrote:
>
> This fixes an unnecessary empty line that we add to the log message when
> we generate diffs, but don't actually end up printing any due to having
> DIFF_FORMAT_NO_OUTPUT set.
Btw, this seems to break a few tests, where the test assumed the extra
newlines at the end of commands like "git show -s" (which also triggered
the extra unnecessary padding between commit text and the suppressed
diff).
I think the patch is correct, but the tests obviously would need fixing
before this patch should be applied.
Linus
^ permalink raw reply
* Re: Git User's Survey 2007 unfinished summary continued
From: Jakub Narebski @ 2007-10-08 20:55 UTC (permalink / raw)
To: git
This is continuation of partial summary of Git User's Survey 2007,
ending at state from 28 September 2007.
The survey can be found here:
http://www.survey.net.nz/survey.php?94e135ff41e871a1ea5bcda3ee1856d9
http://tinyurl.com/26774s
The data this summary is based on can be found here:
http://git.or.cz/gitwiki/GitSurvey2007?action=AttachFile&do=get&target=surveydata.csv
http://tinyurl.com/yusomo
----
There were 683 individual responses
About you
~~~~~~~~~
00. Date of response
Date | Count
------------------------------------------
Before | 7
During | 584
After | 92
------------------------------------------
The ranges 'before', 'during' and 'after' refers to official duration
of Git User's Survey 2007, from 20 August 2007 to 10 September 2007.
Actually they are corrected to take into account the fact that local
date on survey's server (or UTC date) might be different from local
date on user computer, so duration of survey is taken as from
2007-08-19 to 2007-09-11.
Most responses are from the start of survey, 20 and 21 August (133 and
103 responses respectively). If anyone is interested I can provide
full date by date histogram.
Getting started with GIT
~~~~~~~~~~~~~~~~~~~~~~~~
07. What helped you most in learning to use it?
TO DO
646 / 683 non-empty responses
Some of the responses:
* documentation (generic)
* man pages
* examples / usage cases in man pages
* everyday GIT, tutorials and user's manual
* wiki examples
* reading mailing list / comp.version-control.git
* people on IRC (not only #git)
* advice from other users / friends / colleagues
* (unofficial) documentation on the web: guides, articles, blogs etc.
[here probably should be a sublist of them, with count]
* a development community and/or its documentation, mailing list
e.g. WINE wiki, Source Mage GNU/Linux development community
* Google (Google searches)
* helpful error messages
* source code, reading the parts of git in shell script
* cogito
* using git in a live project / experimenting / trial and error
(That I was able to just delete the entire repository and start
over. That all my mistakes stayed local and didn't affect upstream
repos.)
* working on an established project that had documented processes for
using git
* writing code for both plumbing and Porcelain
writing documentation / tutorial for project / article
* understanding the internal representation of the repository;
good / simple design, basic principles; understanding concepts
* experience of working in software industry;
prior experience with version control systems (GNU Arch, SVN, BK, hg)
* version 1.5
* gitk, qgit; git-gui
One of more interesting:
* We hired a consultant to give us a tutorial
08. What did you find hardest?
TO DO
596 / 683 non-empty responses
Some of the responses:
* the level of complexity
* user interface:
too much / inconsistent commands, too many / cryptic options
distinction between plumbing and porcelain
many ways to do a task
insufficient error messages
'git <cmd> --help' prints manpage, not concise help summary
* obtuse command messages
* weak porcelain
e.g. git-update-index very central
* git-merge was plumbing
* remote / tracking branches
fetching, pushing and pulling, synchronizing repositories
the fact that push is not an opposite of pull
understanding the difference between committing and publishing
* handling multiple remote repositories
* merge vs rebase, deciding on proper workflow
working with topic branches
modifying a patch series
* merge defaults (which branch gets merged)
* git vs StGIT: slightly different merge conflict handling
* making it work in non-POSIX environments
working with git on case-insensitive and other strange filesystems
compiling on exotic OS, for example AIX
generating man pages
* lack of / bad / outdated / insufficient / badly structured docs
hard to find something in the documentation
git lingo in documentation, documentation for users who know git
using Cogito in some of documentation
* understanding of concepts, thinking in git way
understanding basic concepts and terminology
* distributed SCM concepts, paradigm shift
idea of non-linear history
* index (staging area): understanding, having it visible
* git-diff not showing added files
* commands named differently from equivalents in other SCM
differences from other SCM: git-commit needs '-a' to commit all
changes, strange semantics of git-add, multiple branches in repo
understanding terminology
* importing history from other SCM (bzr, svn)
* reverting changes, amending commit, undoing a commit
* keeping track of where am I, of which version I'm working with
finding which branch the change was made on
* lerning to use it as maintainer
maintaining "perfect patch series", keeping history clean
rewritig history before 'git rebase -i'
* dealing with merge conflicts
figuring how to undo failed merge and restart it
* learning conventions git expects but didn't document clearly
like commit message formatting
* setting up shared repo / shared server
setting up remote repository
* dealing with modified files (dirty tree) when switching branches,
merging (pulling) and rebasing
* checking out past revisions (or tagged revisions) with the
intention to return to newer revision
* creating independent branch, i.e. branch without ancestry
* exploring the history and previous versions of particular files
which are renamed and/or moved around, especially before --follow
was added
* some hot-shot peple in the community (on the mailing list)
* setting up gitweb
* having to use CLI interface
* no <some language> documentation
More interesting:
* All idiosyncrasies that make (made) sense for Linus' workflow but
aren't really orthogonal or predictable.
* Listening to whiners complain about how hard it was to learn
* Thinking outside the narrow box defined by previous SCMs.
* Not having used an SCM before!
* Following the explosive growth of features.
* Having a day job taking most of my time away from git.
* Convincing my boss to use it.
Conclusions:
- some of the things got corrected, like separate remote layout being
default for non-bare repositories, using git-add (porcelain)
instead of git-update-index (plumbing) in documentation and command
messages, promoting git-merge to porcelain, creating git-remote for
managing multiple repositories and remote branches, better
documentation including creating git user's manual.
- some things are hard because of historical reasons, such like
naming of commands, or consistency of options, and would be
difficult to change.
- doing things "git way", such as making index visible (and requiring
'git commit -a' to commit changes in all files), or rename
detection instead of rename tracking, or storing filenames and file
contents 'as-is' (without translation) are I think here to stay
- some of things are intrinsically hard, and would stay that way,
for example the distributed SCM concept, or nonlinear history.
How you use GIT
~~~~~~~~~~~~~~~
22. What projects do you track (or download) using GIT
(or git web interface)?
TO TABULARIZE
560 / 683 non-empty responses
A note: this question was meant to list projects which one _tracks_,
not the ones he/she maintains, meaning the projects in the remotes
(section).
Tracked projects can be divided into the following categories:
* undisclosed: proprietary code / work projects, own projects, etc.
* Linux kernel an kernel related projects (like udev or kvm)
* git related: git, gitk, git-gui, git-gui-i18n, stgit, tig,...
* freedesktop (and related) projects: XCB, Compiz, Mesa3D, Cairo,...
* Linux distributions: Source Mage, Slind,... (a few)
* tracked via git-svn, e.g. nsd, KDE, GIMP, FreeCiv
* others with official git repositories (like XMMS2 or ELinks)
* others with unofficial git repositories (like OpenOffice.org)
There are more that 100 different projects tracked mentioned in survey
(not all of them _choose_ git as their SCM).
Internationalization
~~~~~~~~~~~~~~~~~~~~
32. What do you need translated?
TO TABULARIZE
172 / 683 non-empty responses
Summary of responses, without count (which I guess is most important):
* user interface: command messages and error messages
* GUI: git-gui, gitk
* man pages and commands usage
('git <cmd> --help' , git <cmd> --usage')
* user's manual, tutorials, intro, howtos
* website / homepage
--
Jakub Narebski
Poland
(temporarily away from Internet)
^ permalink raw reply
* [PATCH] mergetool: add support for ECMerge
From: Steffen Prohaska @ 2007-10-08 21:22 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: git, Steffen Prohaska
In-Reply-To: <11918785613855-git-send-email-prohaska@zib.de>
Add support for ECMerge available from
http://www.elliecomputing.com/Products/merge_overview.asp
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Documentation/git-mergetool.txt | 2 +-
git-mergetool.sh | 12 +++++++++++-
2 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 6b97aaa..ece7718 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -25,7 +25,7 @@ OPTIONS
-t or --tool=<tool>::
Use the merge resolution program specified by <tool>.
Valid merge tools are:
- kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, and opendiff
+ kdiff3, tkdiff, meld, xxdiff, emerge, vimdiff, gvimdiff, ecmerge, and opendiff
+
If a merge resolution program is not specified, 'git mergetool'
will use the configuration variable merge.tool. If the
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 7f6c16f..39f6595 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -250,6 +250,16 @@ merge_file () {
check_unchanged
save_backup
;;
+ ecmerge)
+ touch "$BACKUP"
+ if base_present; then
+ "$merge_tool_path" "$BASE" "$LOCAL" "$REMOTE" --mode=merge3 --to="$path"
+ else
+ "$merge_tool_path" "$LOCAL" "$REMOTE" --mode=merge2 --to="$path"
+ fi
+ check_unchanged
+ save_backup
+ ;;
emerge)
if base_present ; then
"$merge_tool_path" -f emerge-files-with-ancestor-command "$LOCAL" "$REMOTE" "$BASE" "$(basename "$path")"
@@ -299,7 +309,7 @@ done
valid_tool() {
case "$1" in
- kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff)
+ kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | ecmerge)
;; # happy
*)
return 1
--
1.5.3.3.127.g40d17
^ permalink raw reply related
* [PATCH] mergetool: support absolute paths to tools by git config merge.<tool>path
From: Steffen Prohaska @ 2007-10-08 21:22 UTC (permalink / raw)
To: Theodore Ts'o; +Cc: git, Steffen Prohaska
This commit adds a mechanism to provide absolute paths to the
commands called by 'git mergetool'. A path can be specified
in the configuation variable merge.<toolname>path.
This mechanism is especially useful on Windows, where external
programs are unlikely to be in the path.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
---
Documentation/git-mergetool.txt | 5 ++
git-mergetool.sh | 81 ++++++++++++++++++++++-----------------
2 files changed, 51 insertions(+), 35 deletions(-)
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index 6c32c6d..6b97aaa 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -31,6 +31,11 @@ If a merge resolution program is not specified, 'git mergetool'
will use the configuration variable merge.tool. If the
configuration variable merge.tool is not set, 'git mergetool'
will pick a suitable default.
++
+You can explicitly provide a full path to the tool by setting the
+configuration variable merge.<tool>path. For example, you
+can configure the absolute path to kdiff3 by setting merge.kdiff3path.
+Otherise, 'git mergetool' assumes the tool is available in PATH.
Author
------
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 9f4f313..7f6c16f 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -192,10 +192,10 @@ merge_file () {
case "$merge_tool" in
kdiff3)
if base_present ; then
- (kdiff3 --auto --L1 "$path (Base)" --L2 "$path (Local)" --L3 "$path (Remote)" \
+ ("$merge_tool_path" --auto --L1 "$path (Base)" --L2 "$path (Local)" --L3 "$path (Remote)" \
-o "$path" -- "$BASE" "$LOCAL" "$REMOTE" > /dev/null 2>&1)
else
- (kdiff3 --auto --L1 "$path (Local)" --L2 "$path (Remote)" \
+ ("$merge_tool_path" --auto --L1 "$path (Local)" --L2 "$path (Remote)" \
-o "$path" -- "$LOCAL" "$REMOTE" > /dev/null 2>&1)
fi
status=$?
@@ -203,35 +203,35 @@ merge_file () {
;;
tkdiff)
if base_present ; then
- tkdiff -a "$BASE" -o "$path" -- "$LOCAL" "$REMOTE"
+ "$merge_tool_path" -a "$BASE" -o "$path" -- "$LOCAL" "$REMOTE"
else
- tkdiff -o "$path" -- "$LOCAL" "$REMOTE"
+ "$merge_tool_path" -o "$path" -- "$LOCAL" "$REMOTE"
fi
status=$?
save_backup
;;
meld|vimdiff)
touch "$BACKUP"
- $merge_tool -- "$LOCAL" "$path" "$REMOTE"
+ "$merge_tool_path" -- "$LOCAL" "$path" "$REMOTE"
check_unchanged
save_backup
;;
gvimdiff)
touch "$BACKUP"
- gvimdiff -f -- "$LOCAL" "$path" "$REMOTE"
+ "$merge_tool_path" -f -- "$LOCAL" "$path" "$REMOTE"
check_unchanged
save_backup
;;
xxdiff)
touch "$BACKUP"
if base_present ; then
- xxdiff -X --show-merged-pane \
+ "$merge_tool_path" -X --show-merged-pane \
-R 'Accel.SaveAsMerged: "Ctrl-S"' \
-R 'Accel.Search: "Ctrl+F"' \
-R 'Accel.SearchForward: "Ctrl-G"' \
--merged-file "$path" -- "$LOCAL" "$BASE" "$REMOTE"
else
- xxdiff -X --show-merged-pane \
+ "$merge_tool_path" -X --show-merged-pane \
-R 'Accel.SaveAsMerged: "Ctrl-S"' \
-R 'Accel.Search: "Ctrl+F"' \
-R 'Accel.SearchForward: "Ctrl-G"' \
@@ -243,18 +243,18 @@ merge_file () {
opendiff)
touch "$BACKUP"
if base_present; then
- opendiff "$LOCAL" "$REMOTE" -ancestor "$BASE" -merge "$path" | cat
+ "$merge_tool_path" "$LOCAL" "$REMOTE" -ancestor "$BASE" -merge "$path" | cat
else
- opendiff "$LOCAL" "$REMOTE" -merge "$path" | cat
+ "$merge_tool_path" "$LOCAL" "$REMOTE" -merge "$path" | cat
fi
check_unchanged
save_backup
;;
emerge)
if base_present ; then
- emacs -f emerge-files-with-ancestor-command "$LOCAL" "$REMOTE" "$BASE" "$(basename "$path")"
+ "$merge_tool_path" -f emerge-files-with-ancestor-command "$LOCAL" "$REMOTE" "$BASE" "$(basename "$path")"
else
- emacs -f emerge-files-command "$LOCAL" "$REMOTE" "$(basename "$path")"
+ "$merge_tool_path" -f emerge-files-command "$LOCAL" "$REMOTE" "$(basename "$path")"
fi
status=$?
save_backup
@@ -297,17 +297,23 @@ do
shift
done
+valid_tool() {
+ case "$1" in
+ kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff)
+ ;; # happy
+ *)
+ return 1
+ ;;
+ esac
+}
+
if test -z "$merge_tool"; then
merge_tool=`git config merge.tool`
- case "$merge_tool" in
- kdiff3 | tkdiff | xxdiff | meld | opendiff | emerge | vimdiff | gvimdiff | "")
- ;; # happy
- *)
+ test -n "$merge_tool" || valid_tool "$merge_tool" || {
echo >&2 "git config option merge.tool set to unknown tool: $merge_tool"
echo >&2 "Resetting to default..."
unset merge_tool
- ;;
- esac
+ }
fi
if test -z "$merge_tool" ; then
@@ -345,24 +351,29 @@ if test -z "$merge_tool" ; then
fi
fi
-case "$merge_tool" in
- kdiff3|tkdiff|meld|xxdiff|vimdiff|gvimdiff|opendiff)
- if ! type "$merge_tool" > /dev/null 2>&1; then
- echo "The merge tool $merge_tool is not available"
- exit 1
- fi
- ;;
- emerge)
- if ! type "emacs" > /dev/null 2>&1; then
- echo "Emacs is not available"
- exit 1
- fi
- ;;
- *)
- echo "Unknown merge tool: $merge_tool"
+valid_tool "$merge_tool" || {
+ echo >&2 "Unknown merge_tool $merge_tool"
exit 1
- ;;
-esac
+}
+
+if test -z "$merge_tool_path" ; then
+ merge_tool_path=`git config merge.${merge_tool}path`
+ if test -z "$merge_tool_path" ; then
+ case "$merge_tool" in
+ emerge)
+ merge_tool_path=emacs
+ ;;
+ *)
+ merge_tool_path=$merge_tool
+ ;;
+ esac
+ fi
+fi
+
+if ! type "$merge_tool_path" > /dev/null 2>&1; then
+ echo "The merge tool $merge_tool is not available as '$merge_tool_path'"
+ exit 1
+fi
if test $# -eq 0 ; then
files=`git ls-files -u | sed -e 's/^[^ ]* //' | sort -u`
--
1.5.3.3.127.g40d17
^ permalink raw reply related
* Re: [PATCH] mergetool: add support for ECMerge
From: Theodore Tso @ 2007-10-08 21:44 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11918785611059-git-send-email-prohaska@zib.de>
On Mon, Oct 08, 2007 at 11:22:41PM +0200, Steffen Prohaska wrote:
> Add support for ECMerge available from
> http://www.elliecomputing.com/Products/merge_overview.asp
Hmm. A propietary merge tool. It's not that much code, so I guess....
I note though that it claims on the web page that they are integrated
with "most famous SCM's", but they don't include git. If we add this
support, are they going to change their web page? :-)
Also, ECmerge is supported on Linux, Solaris, MacOS X, and Windows.
Which platforms have you tested on? My guess is that if it works on
Linux, it'll probably work on Solaris and MacOS, but is it a fair
guess you haven't tested under Windows? Not that most Windows systems
are going to be able to use git-mergetool since it's a bash script,
unless they are using Cygwin or some such.
- Ted
^ permalink raw reply
* Re: [PATCH] mergetool: support absolute paths to tools by git config merge.<tool>path
From: Theodore Tso @ 2007-10-08 21:57 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <11918785613855-git-send-email-prohaska@zib.de>
On Mon, Oct 08, 2007 at 11:22:40PM +0200, Steffen Prohaska wrote:
> This commit adds a mechanism to provide absolute paths to the
> commands called by 'git mergetool'. A path can be specified
> in the configuation variable merge.<toolname>path.
This patch doesn't work the config file doesn't specify an explicit
mergetool via merge.tool. The reason for that is this loop:
for i in $merge_tool_candidates; do
if test $i = emerge ; then
cmd=emacs
else
cmd=$i
fi
if type $cmd > /dev/null 2>&1; then
merge_tool=$i
break
fi
done
is only checking to see if $cmd is in the path; it's not looking up
the merge.<toolname>path variable in this loop.
I guess the other question is whether we would be better off simply
telling the user to specify an absolute pathname in merge.tool, and
then having git-mergetool strip off the directory path via basename,
and then on window systems, stripping off the .EXE or .COM suffix, and
then downcasing the name so that something like "C:\Program
Files\ECMerge\ECMerge.exe" gets translated to "ecmerge". Would I be
right in guessing that the reason why you used merge.<toolname>path
approach was to avoid this messy headache?
- Ted
^ permalink raw reply
* Re: [PATCH] mergetool: support absolute paths to tools by git config merge.<tool>path
From: Frank Lichtenheld @ 2007-10-08 22:00 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Theodore Ts'o, git
In-Reply-To: <11918785613855-git-send-email-prohaska@zib.de>
On Mon, Oct 08, 2007 at 11:22:40PM +0200, Steffen Prohaska wrote:
> This commit adds a mechanism to provide absolute paths to the
> commands called by 'git mergetool'. A path can be specified
> in the configuation variable merge.<toolname>path.
Why not merge.<toolname>.path?
This would it make easy to introduce new variables of the form
merge.<toolname>.<var> later if needed. I also think it is more
consistent with names of existing configuration variables.
(think branch.<name>.<var> or remote.<name>.<var>)
Gruesse,
--
Frank Lichtenheld <frank@lichtenheld.de>
www: http://www.djpig.de/
^ permalink raw reply
* Re: [PATCH] mergetool: support absolute paths to tools by git config merge.<tool>path
From: Theodore Tso @ 2007-10-08 22:01 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: git
In-Reply-To: <20071008215729.GC31713@thunk.org>
On Mon, Oct 08, 2007 at 05:57:29PM -0400, Theodore Tso wrote:
> This patch doesn't work the config file doesn't specify an explicit
> mergetool via merge.tool. The reason for that is this loop:
Err, let me try that again. "This patch doesn't work IF the config
file doesn't specify an explicit > mergetool via merge.tool."
Sorry about the missing conjuction; the sentence doesn't make much
sense without it...
- Ted
^ permalink raw reply
* confused about a conflict during octopus merging
From: martin f krafft @ 2007-10-09 0:31 UTC (permalink / raw)
To: git discussion list
[-- Attachment #1: Type: text/plain, Size: 2419 bytes --]
Dear list,
I am a little confused why the following yields a conflict:
$ git init
$ touch a; git add a; git commit -ma
Created initial commit 0ba90cc: a
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 a
# create merger branch for later
$ git branch merger
# create a file
$ date > d; git add d; git commit -md1
Created commit 89d22eb: d
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 d
# branch off a second branch and populate it
$ git checkout -b second
Switched to a new branch "second"
$ touch b; git add b; git commit -mb
Created commit 7370737: b
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 b
# modify file changed in previous commit
$ git checkout master
Switched to branch "master"
$ date >> d; git add d; git commit -md2
Created commit bb5f1b4: d2
1 files changed, 1 insertions(+), 1 deletions(-)
Now the tree structure is
x -- master: d2
| x -- second: b
|/
x d1
|
x -- merger: a
# now octopus-merge master+second into merger
$ git checkout merger
Switched to branch "merger"
$ git merge master second
Trying simple merge with bb5f1b4f3a8cbfcbc9dbc97cc823f3ca05db2db1
Trying simple merge with 7370737ff3aa6540a425db015e194766d2cbda2e
Simple merge did not work, trying automatic merge.
Added d in both, but differently.
error: Could not read .merge_file_mCwa4W
ERROR: Merge conflict in d
fatal: merge program failed
Automatic merge failed; fix conflicts and then commit the result.
I don't understand why these conflict. I mean, sure, it makes sense:
after merging master, file d is at d2. Now when merging second, it
tries to replace d by its ancestor, d1.
What I don't understand is why Git does not understand that commit
d is part of the path of arriving at d2, so when 'second' is merged,
Git *should* really see that the change to file d in 'second' (d1)
is an ancestor of the already present d2 commit, and *not* conflict.
What am I misunderstanding here?
Thanks,
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
"distrust all those who love you extremely
upon a very slight acquaintance and without any visible reason."
-- lord chesterfield
spamtraps: madduck.bogus@madduck.net
[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [TIG PATCH] Add missing = for comparison in obsolete actions check.
From: Jonas Fonseca @ 2007-10-09 0:53 UTC (permalink / raw)
To: James Bowes; +Cc: git
In-Reply-To: <20071008173034.GA27292@crux.toronto.redhat.com>
James Bowes <jbowes@dangerouslyinc.com> wrote Mon, Oct 08, 2007:
> Signed-off-by: James Bowes <jbowes@dangerouslyinc.com>
> ---
> tig.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/tig.c b/tig.c
> index 933d083..30c505b 100644
> --- a/tig.c
> +++ b/tig.c
> @@ -1184,7 +1184,7 @@ option_bind_command(int argc, char *argv[])
> }
>
> request = get_request(argv[2]);
> - if (request = REQ_NONE) {
> + if (request == REQ_NONE) {
> const char *obsolete[] = { "cherry-pick" };
> size_t namelen = strlen(argv[2]);
> int i;
Oops, thanks. I should readd -Wall to CFLAGS in my config.make file.
--
Jonas Fonseca
^ permalink raw reply
* bug? - git-checkout treeish paths ignores deleted files
From: Mark Levedahl @ 2007-10-09 0:58 UTC (permalink / raw)
To: Git Mailing List
Shouldn't "git checkout topic path" make the directory tree rooted at
path identical to what is on branch topic? It doesn't.
Try this:
mkdir test
cd test
git init
touch a b
git add a b
git commit -m 'base'
git checkout -b topic
git rm a
git commit -m 'removed a'
git checkout master
git checkout topic .
...and the result is...
ls
a b
instead of
b
Mark
^ permalink raw reply
* Re: confused about a conflict during octopus merging
From: Linus Torvalds @ 2007-10-09 1:21 UTC (permalink / raw)
To: martin f krafft; +Cc: git discussion list
In-Reply-To: <20071009003156.GA30498@lapse.madduck.net>
On Tue, 9 Oct 2007, martin f krafft wrote:
>
> I am a little confused why the following yields a conflict:
Octopus merges are special. Don't use them unless you really know what
you're doing. And generally not even then ;)
> $ git merge master second
> Trying simple merge with bb5f1b4f3a8cbfcbc9dbc97cc823f3ca05db2db1
> Trying simple merge with 7370737ff3aa6540a425db015e194766d2cbda2e
> Simple merge did not work, trying automatic merge.
> Added d in both, but differently.
> error: Could not read .merge_file_mCwa4W
> ERROR: Merge conflict in d
> fatal: merge program failed
> Automatic merge failed; fix conflicts and then commit the result.
>
> I don't understand why these conflict. I mean, sure, it makes sense:
> after merging master, file d is at d2. Now when merging second, it
> tries to replace d by its ancestor, d1.
Right. It makes total sense, because an octopus merge is simply always
going to create a whole new merge commit that goes through the sources one
by one, and merges them in - and if you do that, then you get a conflict
in "d".
> What I don't understand is why Git does not understand that commit
> d is part of the path of arriving at d2, so when 'second' is merged,
> Git *should* really see that the change to file d in 'second' (d1)
> is an ancestor of the already present d2 commit, and *not* conflict.
>
> What am I misunderstanding here?
Octopus merges do *not* fast-forward. Maybe they should. But they don't.
So when the octopus merge starts merging in "master" into the "merger"
branch, it will *not* just fast-forward the branch to "master". Instead,
if will generate a new tree that is basically the merged state: but that
new tree is *not* the same as the master commit, it's literally a merge of
the two branches - which in practice means that it has the same *content*
as master, but it's not at that commit.
So that first stage of the octopus merge has gone fine, but it didn't
really do what you expected.
And so now we have a half-way done octopus merge, with the first branch
added. Now it merges in the second branch ("second"), and it *still* has
the merge base being the original merge base, namely "merger".
And from that standpoint, it really *is* a conflict.
I do think that
- octopus merges should probably refuse to happen when a branch isn't a
"merge" at all, but a fast-forward.
*or*
- we should make octopus-merges smarter, and for each branch that is a
fast-forward, it really just fast-forwards.
but I don't think the current behaviour is "wrong", it's just not what you
expected.
If you think of octopus merges as a really stupid thing where git will
mindlessly do a three-way merge based on the *current* state with all the
branches you name, then you get the current octopus merge. You just
expected it to be smarter than it is, probably because you compare it to
the *real* merge.
Linus
^ permalink raw reply
* Re: bug? - git-checkout treeish paths ignores deleted files
From: Wincent Colaiuta @ 2007-10-09 1:52 UTC (permalink / raw)
To: Mark Levedahl; +Cc: Git Mailing List
In-Reply-To: <470AD21E.6070906@gmail.com>
El 9/10/2007, a las 2:58, Mark Levedahl escribió:
> Shouldn't "git checkout topic path" make the directory tree
> rooted at path identical to what is on branch topic? It doesn't.
>
> Try this:
>
> mkdir test
> cd test
> git init
> touch a b
> git add a b
> git commit -m 'base'
> git checkout -b topic
> git rm a
> git commit -m 'removed a'
> git checkout master
> git checkout topic .
>
> ...and the result is...
> ls
> a b
>
> instead of
> b
No, the behaviour is correct.
- first you removed the file on the topic branch; at the same time
you removed it from your working tree
- then you switched back to the master branch and so the file was
added back to your working tree
- then you switched back to the topic branch, and seeing as the file
"a" is not being tracked in the topic branch Git doesn't touch it
In general, Git only meddles with stuff that you've told it to track.
This is actually a good thing in most cases because it makes some
workflows involving dirty trees or trees with untracked content
somewhat more convenient.
Cheers,
Wincent
^ permalink raw reply
* Re: bug? - git-checkout treeish paths ignores deleted files
From: Mark Levedahl @ 2007-10-09 3:39 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Git Mailing List
In-Reply-To: <3B0685AB-0725-4473-8AE6-359F93851C10@wincent.com>
Wincent Colaiuta wrote:
> El 9/10/2007, a las 2:58, Mark Levedahl escribió:
>
>> Shouldn't "git checkout topic path" make the directory tree rooted
>> at path identical to what is on branch topic? It doesn't.
>>
>>
>
> No, the behaviour is correct.
>
> - first you removed the file on the topic branch; at the same time you
> removed it from your working tree
> - then you switched back to the master branch and so the file was
> added back to your working tree
> - then you switched back to the topic branch, and seeing as the file
> "a" is not being tracked in the topic branch Git doesn't touch it
>
> In general, Git only meddles with stuff that you've told it to track.
> This is actually a good thing in most cases because it makes some
> workflows involving dirty trees or trees with untracked content
> somewhat more convenient.
>
> Cheers,
> Wincent
>
>
I'm not convinced...
"git checkout branch dir" should make dir have the same value it would
get if I just did "git checkout branch". The latter command will ignore
files only if they are untracked in *both* HEAD and branch. I fail to
see why the path-limited version of git-checkout should give a different
result on the part it is asked to affect than the non-path limited
version. This is very inconsistent and I'm having a hard time
understanding what workflow it will help.
Mark
^ permalink raw reply
* [PATCH 1/3] rev-list: implement --bisect-all
From: Christian Couder @ 2007-10-09 4:25 UTC (permalink / raw)
To: Junio Hamano, Johannes Schindelin; +Cc: git
This is Junio's patch with some stuff to make --bisect-all
compatible with --bisect-vars.
This option makes it possible to see all the potential
bisection points. The best ones are displayed first.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
builtin-rev-list.c | 100 ++++++++++++++++++++++++++++++++++++++++++++-------
log-tree.c | 2 +-
log-tree.h | 1 +
3 files changed, 88 insertions(+), 15 deletions(-)
There is a a small change in the second hunk
compared to the patch I sent yesterday.
diff --git a/builtin-rev-list.c b/builtin-rev-list.c
index 33726b8..4439332 100644
--- a/builtin-rev-list.c
+++ b/builtin-rev-list.c
@@ -9,6 +9,7 @@
#include "revision.h"
#include "list-objects.h"
#include "builtin.h"
+#include "log-tree.h"
/* bits #0-15 in revision.h */
@@ -38,7 +39,8 @@ static const char rev_list_usage[] =
" --left-right\n"
" special purpose:\n"
" --bisect\n"
-" --bisect-vars"
+" --bisect-vars\n"
+" --bisect-all"
;
static struct rev_info revs;
@@ -74,6 +76,7 @@ static void show_commit(struct commit *commit)
parents = parents->next;
}
}
+ show_decorations(commit);
if (revs.commit_format == CMIT_FMT_ONELINE)
putchar(' ');
else
@@ -278,6 +281,57 @@ static struct commit_list *best_bisection(struct commit_list *list, int nr)
return best;
}
+struct commit_dist {
+ struct commit *commit;
+ int distance;
+};
+
+static int compare_commit_dist(const void *a_, const void *b_)
+{
+ struct commit_dist *a, *b;
+
+ a = (struct commit_dist *)a_;
+ b = (struct commit_dist *)b_;
+ if (a->distance != b->distance)
+ return b->distance - a->distance; /* desc sort */
+ return hashcmp(a->commit->object.sha1, b->commit->object.sha1);
+}
+
+static struct commit_list *best_bisection_sorted(struct commit_list *list, int nr)
+{
+ struct commit_list *p;
+ struct commit_dist *array = xcalloc(nr, sizeof(*array));
+ int cnt, i;
+
+ for (p = list, cnt = 0; p; p = p->next) {
+ int distance;
+ unsigned flags = p->item->object.flags;
+
+ if (revs.prune_fn && !(flags & TREECHANGE))
+ continue;
+ distance = weight(p);
+ if (nr - distance < distance)
+ distance = nr - distance;
+ array[cnt].commit = p->item;
+ array[cnt].distance = distance;
+ cnt++;
+ }
+ qsort(array, cnt, sizeof(*array), compare_commit_dist);
+ for (p = list, i = 0; i < cnt; i++) {
+ struct name_decoration *r = xmalloc(sizeof(*r) + 100);
+ struct object *obj = &(array[i].commit->object);
+
+ sprintf(r->name, "dist=%d", array[i].distance);
+ r->next = add_decoration(&name_decoration, obj, r);
+ p->item = array[i].commit;
+ p = p->next;
+ }
+ if (p)
+ p->next = NULL;
+ free(array);
+ return list;
+}
+
/*
* zero or positive weight is the number of interesting commits it can
* reach, including itself. Especially, weight = 0 means it does not
@@ -292,7 +346,8 @@ static struct commit_list *best_bisection(struct commit_list *list, int nr)
* or positive distance.
*/
static struct commit_list *do_find_bisection(struct commit_list *list,
- int nr, int *weights)
+ int nr, int *weights,
+ int find_all)
{
int n, counted;
struct commit_list *p;
@@ -351,7 +406,7 @@ static struct commit_list *do_find_bisection(struct commit_list *list,
clear_distance(list);
/* Does it happen to be at exactly half-way? */
- if (halfway(p, nr))
+ if (!find_all && halfway(p, nr))
return p;
counted++;
}
@@ -389,19 +444,22 @@ static struct commit_list *do_find_bisection(struct commit_list *list,
weight_set(p, weight(q));
/* Does it happen to be at exactly half-way? */
- if (halfway(p, nr))
+ if (!find_all && halfway(p, nr))
return p;
}
}
show_list("bisection 2 counted all", counted, nr, list);
- /* Then find the best one */
- return best_bisection(list, nr);
+ if (!find_all)
+ return best_bisection(list, nr);
+ else
+ return best_bisection_sorted(list, nr);
}
static struct commit_list *find_bisection(struct commit_list *list,
- int *reaches, int *all)
+ int *reaches, int *all,
+ int find_all)
{
int nr, on_list;
struct commit_list *p, *best, *next, *last;
@@ -434,14 +492,13 @@ static struct commit_list *find_bisection(struct commit_list *list,
weights = xcalloc(on_list, sizeof(*weights));
/* Do the real work of finding bisection commit. */
- best = do_find_bisection(list, nr, weights);
-
+ best = do_find_bisection(list, nr, weights, find_all);
if (best) {
- best->next = NULL;
+ if (!find_all)
+ best->next = NULL;
*reaches = weight(best);
}
free(weights);
-
return best;
}
@@ -468,6 +525,7 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
int i;
int read_from_stdin = 0;
int bisect_show_vars = 0;
+ int bisect_find_all = 0;
git_config(git_default_config);
init_revisions(&revs, prefix);
@@ -490,6 +548,11 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
bisect_list = 1;
continue;
}
+ if (!strcmp(arg, "--bisect-all")) {
+ bisect_list = 1;
+ bisect_find_all = 1;
+ continue;
+ }
if (!strcmp(arg, "--bisect-vars")) {
bisect_list = 1;
bisect_show_vars = 1;
@@ -536,9 +599,11 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
if (bisect_list) {
int reaches = reaches, all = all;
- revs.commits = find_bisection(revs.commits, &reaches, &all);
+ revs.commits = find_bisection(revs.commits, &reaches, &all,
+ bisect_find_all);
if (bisect_show_vars) {
int cnt;
+ char hex[41];
if (!revs.commits)
return 1;
/*
@@ -550,15 +615,22 @@ int cmd_rev_list(int argc, const char **argv, const char *prefix)
* A bisect set of size N has (N-1) commits further
* to test, as we already know one bad one.
*/
- cnt = all-reaches;
+ cnt = all - reaches;
if (cnt < reaches)
cnt = reaches;
+ strcpy(hex, sha1_to_hex(revs.commits->item->object.sha1));
+
+ if (bisect_find_all) {
+ traverse_commit_list(&revs, show_commit, show_object);
+ printf("------\n");
+ }
+
printf("bisect_rev=%s\n"
"bisect_nr=%d\n"
"bisect_good=%d\n"
"bisect_bad=%d\n"
"bisect_all=%d\n",
- sha1_to_hex(revs.commits->item->object.sha1),
+ hex,
cnt - 1,
all - reaches - 1,
reaches - 1,
diff --git a/log-tree.c b/log-tree.c
index 2319154..f766758 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -15,7 +15,7 @@ static void show_parents(struct commit *commit, int abbrev)
}
}
-static void show_decorations(struct commit *commit)
+void show_decorations(struct commit *commit)
{
const char *prefix;
struct name_decoration *decoration;
diff --git a/log-tree.h b/log-tree.h
index e82b56a..b33f7cd 100644
--- a/log-tree.h
+++ b/log-tree.h
@@ -12,5 +12,6 @@ int log_tree_diff_flush(struct rev_info *);
int log_tree_commit(struct rev_info *, struct commit *);
int log_tree_opt_parse(struct rev_info *, const char **, int);
void show_log(struct rev_info *opt, const char *sep);
+void show_decorations(struct commit *commit);
#endif
--
1.5.3.4.209.g5612
^ permalink raw reply related
* [PATCH 2/3] Bisect: fix some white spaces and empty lines breakages.
From: Christian Couder @ 2007-10-09 4:25 UTC (permalink / raw)
To: Junio Hamano, Johannes Schindelin; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 17 ++++++++---------
1 files changed, 8 insertions(+), 9 deletions(-)
This is a new patch where I put some trivial
stuff to avoid distracting Dscho.
diff --git a/git-bisect.sh b/git-bisect.sh
index 388887a..436ccf6 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -64,7 +64,7 @@ bisect_start() {
branch=`cat "$GIT_DIR/head-name"`
else
branch=master
- fi
+ fi
git checkout $branch || exit
;;
refs/heads/*)
@@ -95,11 +95,11 @@ bisect_start() {
arg="$1"
case "$arg" in
--)
- shift
+ shift
break
;;
*)
- rev=$(git rev-parse --verify "$arg^{commit}" 2>/dev/null) || {
+ rev=$(git rev-parse --verify "$arg^{commit}" 2>/dev/null) || {
test $has_double_dash -eq 1 &&
die "'$arg' does not appear to be a valid revision"
break
@@ -110,10 +110,10 @@ bisect_start() {
else
bisect_write_good "$rev"
fi
- shift
+ shift
;;
esac
- done
+ done
sq "$@" >"$GIT_DIR/BISECT_NAMES"
echo "git-bisect start$orig_args" >>"$GIT_DIR/BISECT_LOG"
@@ -143,7 +143,7 @@ bisect_write_bad() {
bisect_good() {
bisect_autostart
- case "$#" in
+ case "$#" in
0) revs=$(git rev-parse --verify HEAD) || exit ;;
*) revs=$(git rev-parse --revs-only --no-flags "$@") &&
test '' != "$revs" || die "Bad rev input: $@" ;;
@@ -153,7 +153,6 @@ bisect_good() {
rev=$(git rev-parse --verify "$rev^{commit}") || exit
bisect_write_good "$rev"
echo "git-bisect good $rev" >>"$GIT_DIR/BISECT_LOG"
-
done
bisect_auto_next
}
@@ -207,7 +206,7 @@ bisect_auto_next() {
}
bisect_next() {
- case "$#" in 0) ;; *) usage ;; esac
+ case "$#" in 0) ;; *) usage ;; esac
bisect_autostart
bisect_next_check good
@@ -255,7 +254,7 @@ bisect_reset() {
exit 1
}
branch="$1" ;;
- *)
+ *)
usage ;;
esac
if git checkout "$branch"; then
--
1.5.3.4.209.g5612
^ permalink raw reply related
* [PATCH 3/3] Bisect: implement "bisect dunno" to mark untestable revisions.
From: Christian Couder @ 2007-10-09 4:25 UTC (permalink / raw)
To: Junio Hamano, Johannes Schindelin; +Cc: git
When there are some dunno revisions, we add the '--bisect-all'
option to "git rev-list --bisect-vars". Then we filter out the
dunno revisions from the result of the rev-list command, and we
modify the "bisect_rev" var accordingly.
We don't always use "--bisect-all" because it is slower
than "--bisect-vars" or "--bisect".
When we cannot find for sure the first bad commit because of
dunno commits, we print the hash of each possible first bad
commit and then we exit with code 2.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-bisect.sh | 115 ++++++++++++++++++++++++++++++++++++++++++-
t/t6030-bisect-porcelain.sh | 71 ++++++++++++++++++++++++++
2 files changed, 184 insertions(+), 2 deletions(-)
I removed the "search_dunno" function that was in
the previous version of this patch and replaced it
with a "case" as suggested by Dscho.
I did not removed the bisect_write_{bad,good,dunno}
functions because some of them are used in more than
one place. But I will factorise them in a following
patch.
diff --git a/git-bisect.sh b/git-bisect.sh
index 436ccf6..022671d 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -17,6 +17,8 @@ git bisect replay <logfile>
replay bisection log.
git bisect log
show bisect log.
+git bisect dunno [<rev>...]
+ mark <rev>... untestable revisions.
git bisect run <cmd>...
use <cmd>... to automatically bisect.'
@@ -163,6 +165,28 @@ bisect_write_good() {
echo "# good: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
}
+bisect_dunno() {
+ bisect_autostart
+ case "$#" in
+ 0) revs=$(git rev-parse --verify HEAD) || exit ;;
+ *) revs=$(git rev-parse --revs-only --no-flags "$@") &&
+ test '' != "$revs" || die "Bad rev input: $@" ;;
+ esac
+ for rev in $revs
+ do
+ rev=$(git rev-parse --verify "$rev^{commit}") || exit
+ bisect_write_dunno "$rev"
+ echo "git-bisect dunno $rev" >>"$GIT_DIR/BISECT_LOG"
+ done
+ bisect_auto_next
+}
+
+bisect_write_dunno() {
+ rev="$1"
+ echo "$rev" >"$GIT_DIR/refs/bisect/dunno-$rev"
+ echo "# dunno: "$(git show-branch $rev) >>"$GIT_DIR/BISECT_LOG"
+}
+
bisect_next_check() {
missing_good= missing_bad=
git show-ref -q --verify refs/bisect/bad || missing_bad=t
@@ -205,17 +229,97 @@ bisect_auto_next() {
bisect_next_check && bisect_next || :
}
+filter_dunno() {
+ _eval="$1"
+ _dunno="$2"
+
+ if [ -z "$_dunno" ]; then
+ eval $_eval
+ return
+ fi
+
+ # Let's parse the output of:
+ # "git rev-list --bisect-vars --bisect-all ..."
+ eval $_eval | while read hash line
+ do
+ case "$VARS,$FOUND,$TRIED,$hash" in
+ # We display some vars.
+ 1,*,*,*) echo "$hash $line" ;;
+
+ # Split line.
+ ,*,*,---*) ;;
+
+ # We had nothing to search.
+ ,,,bisect_rev*)
+ echo "bisect_rev="
+ VARS=1
+ ;;
+
+ # We did not find a good bisect rev.
+ # This should happen only if the "bad"
+ # commit is also a "dunno" commit.
+ ,,*,bisect_rev*)
+ echo "bisect_rev=$TRIED"
+ VARS=1
+ ;;
+
+ # We are searching.
+ ,,*,*)
+ TRIED="${TRIED:+$TRIED|}$hash"
+ case "$_dunno" in
+ *$hash*) ;;
+ *)
+ echo "bisect_rev=$hash"
+ echo "bisect_tried=\"$TRIED\""
+ FOUND=1
+ ;;
+ esac
+ ;;
+
+ # We have already found a rev to be tested.
+ ,1,*,bisect_rev*) VARS=1 ;;
+ ,1,*,*) ;;
+
+ # ???
+ *) die "filter_dunno error " \
+ "VARS: '$VARS' " \
+ "FOUND: '$FOUND' " \
+ "TRIED: '$TRIED' " \
+ "hash: '$hash' " \
+ "line: '$line'"
+ ;;
+ esac
+ done
+}
+
+exit_if_dunno_commits () {
+ _tried=$1
+ if expr "$_tried" : ".*[|].*" > /dev/null ; then
+ echo "There are only 'dunno' commit left to test."
+ echo "The first bad commit could be any of:"
+ echo "$_tried" | sed -e 's/[|]/\n/g'
+ echo "We cannot bisect more!"
+ exit 2
+ fi
+}
+
bisect_next() {
case "$#" in 0) ;; *) usage ;; esac
bisect_autostart
bisect_next_check good
+ dunno=$(git for-each-ref --format='%(objectname)' \
+ "refs/bisect/dunno-*" | tr '[\012]' ' ') || exit
+
+ BISECT_OPT=''
+ test -n "$dunno" && BISECT_OPT='--bisect-all'
+
bad=$(git rev-parse --verify refs/bisect/bad) &&
good=$(git for-each-ref --format='^%(objectname)' \
"refs/bisect/good-*" | tr '[\012]' ' ') &&
- eval="git rev-list --bisect-vars $good $bad --" &&
+ eval="git rev-list --bisect-vars $BISECT_OPT $good $bad --" &&
eval="$eval $(cat "$GIT_DIR/BISECT_NAMES")" &&
- eval=$(eval "$eval") &&
+ eval=$(filter_dunno "$eval" "$dunno") &&
eval "$eval" || exit
if [ -z "$bisect_rev" ]; then
@@ -223,11 +327,16 @@ bisect_next() {
exit 1
fi
if [ "$bisect_rev" = "$bad" ]; then
+ exit_if_dunno_commits "$bisect_tried"
echo "$bisect_rev is first bad commit"
git diff-tree --pretty $bisect_rev
exit 0
fi
+ # We should exit here only if the "bad"
+ # commit is also a "dunno" commit (see above).
+ exit_if_dunno_commits "$bisect_rev"
+
echo "Bisecting: $bisect_nr revisions left to test after this"
echo "$bisect_rev" >"$GIT_DIR/refs/heads/new-bisect"
git checkout -q new-bisect || exit
@@ -362,6 +471,8 @@ case "$#" in
bisect_bad "$@" ;;
good)
bisect_good "$@" ;;
+ dunno)
+ bisect_dunno "$@" ;;
next)
# Not sure we want "next" at the UI level anymore.
bisect_next "$@" ;;
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index 03cdba5..7f41a46 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -71,6 +71,63 @@ test_expect_success 'bisect start with one bad and good' '
git bisect next
'
+# $HASH1 is good, $HASH4 is bad, we dunno about $HASH3
+# but $HASH2 is bad,
+# so we should find $HASH2 as the first bad commit
+test_expect_success 'bisect dunno: successfull result' '
+ git bisect reset &&
+ git bisect start $HASH4 $HASH1 &&
+ git bisect dunno &&
+ git bisect bad > my_bisect_log.txt &&
+ grep "$HASH2 is first bad commit" my_bisect_log.txt &&
+ git bisect reset
+'
+
+# $HASH1 is good, $HASH4 is bad, we dunno about $HASH3 and $HASH2
+# so we should not be able to tell the first bad commit
+# among $HASH2, $HASH3 and $HASH4
+test_expect_success 'bisect dunno: cannot tell between 3 commits' '
+ git bisect start $HASH4 $HASH1 &&
+ git bisect dunno || return 1
+
+ if git bisect dunno > my_bisect_log.txt
+ then
+ echo Oops, should have failed.
+ false
+ else
+ test $? -eq 2 &&
+ grep "first bad commit could be any of" my_bisect_log.txt &&
+ ! grep $HASH1 my_bisect_log.txt &&
+ grep $HASH2 my_bisect_log.txt &&
+ grep $HASH3 my_bisect_log.txt &&
+ grep $HASH4 my_bisect_log.txt &&
+ git bisect reset
+ fi
+'
+
+# $HASH1 is good, $HASH4 is bad, we dunno about $HASH3
+# but $HASH2 is good,
+# so we should not be able to tell the first bad commit
+# among $HASH3 and $HASH4
+test_expect_success 'bisect dunno: cannot tell between 2 commits' '
+ git bisect start $HASH4 $HASH1 &&
+ git bisect dunno || return 1
+
+ if git bisect good > my_bisect_log.txt
+ then
+ echo Oops, should have failed.
+ false
+ else
+ test $? -eq 2 &&
+ grep "first bad commit could be any of" my_bisect_log.txt &&
+ ! grep $HASH1 my_bisect_log.txt &&
+ ! grep $HASH2 my_bisect_log.txt &&
+ grep $HASH3 my_bisect_log.txt &&
+ grep $HASH4 my_bisect_log.txt &&
+ git bisect reset
+ fi
+'
+
# We want to automatically find the commit that
# introduced "Another" into hello.
test_expect_success \
@@ -99,6 +156,20 @@ test_expect_success \
grep "$HASH4 is first bad commit" my_bisect_log.txt &&
git bisect reset'
+# $HASH1 is good, $HASH5 is bad, we dunno about $HASH3
+# but $HASH4 is good,
+# so we should find $HASH5 as the first bad commit
+HASH5=
+test_expect_success 'bisect dunno: add line and then a new test' '
+ add_line_into_file "5: Another new line." hello &&
+ HASH5=$(git rev-parse --verify HEAD) &&
+ git bisect start $HASH5 $HASH1 &&
+ git bisect dunno &&
+ git bisect good > my_bisect_log.txt &&
+ grep "$HASH5 is first bad commit" my_bisect_log.txt &&
+ git bisect reset
+'
+
#
#
test_done
--
1.5.3.4.209.g5612
^ permalink raw reply related
* [StGit PATCH] Fix error message generation
From: Karl Hasselström @ 2007-10-09 4:40 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
The right-hand-side operand of % is supposed to be a tuple with the
same number of arguments as there are formatting codes in the
left-hand-side operand, or just any value if there is just one
formatting code; however, here it was a variable with a tuple value,
which didn't work. So wrap it in a tuple of length one, and all is
well again.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
stgit/run.py | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/stgit/run.py b/stgit/run.py
index 989bb27..83bf5f5 100644
--- a/stgit/run.py
+++ b/stgit/run.py
@@ -40,7 +40,7 @@ class Run:
self.__cmd = list(cmd)
for c in cmd:
if type(c) != str:
- raise Exception, 'Bad command: %r' % cmd
+ raise Exception, 'Bad command: %r' % (cmd,)
self.__good_retvals = [0]
self.__env = None
self.__indata = None
^ permalink raw reply related
* [StGit PATCH] New test: "stg diff"
From: Karl Hasselström @ 2007-10-09 4:42 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20071008153450.GA12247@diana.vm.bytemark.co.uk>
A simple test to make sure that we can run "stg diff" without
arguments, just to list local changes.
Note that two subtests currently fail; these are due to plain "stg
diff" failing on a branch where "stg init" hasn't been run, which is
plainly a bug.
Signed-off-by: Karl Hasselström <kha@treskal.com>
---
On 2007-10-08 17:34:50 +0200, Karl Hasselström wrote:
> So, we don't have a single test that tries to run "stg diff". Duh.
t/t2400-diff.sh | 37 +++++++++++++++++++++++++++++++++++++
1 files changed, 37 insertions(+), 0 deletions(-)
create mode 100755 t/t2400-diff.sh
diff --git a/t/t2400-diff.sh b/t/t2400-diff.sh
new file mode 100755
index 0000000..6d9ed98
--- /dev/null
+++ b/t/t2400-diff.sh
@@ -0,0 +1,37 @@
+#!/bin/sh
+
+test_description='Run "stg diff"'
+
+. ./test-lib.sh
+
+test_expect_failure 'Diff with no StGit data' '
+ stg diff
+'
+
+test_expect_success 'Make some local changes' '
+ echo foo >> foo.txt &&
+ git add foo.txt
+'
+
+test_expect_failure 'Diff with some local changes' '
+ stg diff
+'
+
+test_expect_success 'Initialize StGit stuff' '
+ stg init &&
+ stg new foo -m foo
+'
+
+test_expect_success 'Diff with some local changes' '
+ stg diff
+'
+
+test_expect_success 'Refresh patch' '
+ stg refresh
+'
+
+test_expect_success 'Diff with no local changes' '
+ stg diff
+'
+
+test_done
^ 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