* [PATCH 2/2] Make rebase--interactive use OPTIONS_SPEC
From: Stephan Beyer @ 2008-06-20 18:30 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Christian Couder, Stephan Beyer
In-Reply-To: <1213986614-19536-1-git-send-email-s-beyer@gmx.net>
Also add some checks that --continue/--abort/--skip
actions are used without --onto, -p, -t, etc.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
Hi,
Dscho wrote:
> You probably need to introduce checks against "git rebase --continue
> --onto blabla", then.
Now the is_standalone function does that.
Regards,
Stephan
PS: I wondered that nobody moaned that the patch is for pu.
git-rebase--interactive.sh | 71 +++++++++++++++++++++++++++++--------------
1 files changed, 48 insertions(+), 23 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 3f926d8..1894c37 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -10,10 +10,27 @@
# The original idea comes from Eric W. Biederman, in
# http://article.gmane.org/gmane.comp.version-control.git/22407
-USAGE='(--continue | --abort | --skip | [--preserve-merges] [--first-parent]
- [--preserve-tags] [--verbose] [--onto <branch>] <upstream> [<branch>])'
+OPTIONS_KEEPDASHDASH=
+OPTIONS_SPEC="\
+git-rebase [-i] [options] [--] <upstream> [<branch>]
+git-rebase [-i] (--continue | --abort | --skip)
+--
+ Available options are:
+p,preserve-merges Try to recreate merges instead of ignoring them
+t,preserve-tags Update tags to the new commit object
+m,merge Always used (no-op)
+i,interactive Always used (no-op)
+onto= Rebase onto given branch instead of upstream
+v,verbose Display a diffstat of what changed upstream
+ When preserving merges:
+f,first-parent Show only commits following the first parent of each commit
+s,strategy= Use the given merge strategy
+ Actions:
+continue Continue rebasing process
+abort Abort rebasing process and restore original branch
+skip Skip current patch and continue rebasing process
+"
-OPTIONS_SPEC=
. git-sh-setup
require_work_tree
@@ -25,6 +42,8 @@ SQUASH_MSG="$DOTEST"/message-squash
PRESERVE_MERGES=
STRATEGY=
VERBOSE=
+ONTO=
+MARK_PREFIX='refs/rebase-marks'
test -f "$DOTEST"/strategy && STRATEGY="$(cat "$DOTEST"/strategy)"
test -f "$DOTEST"/verbose && VERBOSE=t
@@ -515,10 +534,19 @@ create_extended_todo_list () {
done
}
+is_standalone () {
+ test $# -eq 2 -a "$2" = '--' &&
+ test -z "$ONTO" &&
+ test -z "$PRESERVE_TAGS" &&
+ test -z "$PRESERVE_MERGES" &&
+ test -z "$FIRST_PARENT"
+}
+
while test $# != 0
do
case "$1" in
--continue)
+ is_standalone "$@" || usage
comment_for_reflog continue
test -d "$DOTEST" || die "No interactive rebase running"
@@ -551,6 +579,7 @@ do
do_rest
;;
--abort)
+ is_standalone "$@" || usage
comment_for_reflog abort
git rerere clear
@@ -568,6 +597,7 @@ do
exit
;;
--skip)
+ is_standalone "$@" || usage
comment_for_reflog skip
git rerere clear
@@ -575,7 +605,7 @@ do
output git reset --hard && do_rest
;;
- -s|--strategy)
+ -s)
case "$#,$1" in
*,*=*)
STRATEGY="-s "$(expr "z$1" : 'z-[^=]*=\(.*\)') ;;
@@ -586,32 +616,36 @@ do
shift ;;
esac
;;
- -m|--merge)
+ -m)
# we use merge anyway
;;
- -C*)
- die "Interactive rebase uses merge, so $1 does not make sense"
- ;;
- -v|--verbose)
+ -v)
VERBOSE=t
;;
- -p|--preserve-merges)
+ -p)
PRESERVE_MERGES=t
;;
- -f|--first-parent)
+ -f)
FIRST_PARENT=t
PRESERVE_MERGES=t
;;
- -t|--preserve-tags)
+ -t)
PRESERVE_TAGS=t
;;
- -i|--interactive)
+ -i)
# yeah, we know
;;
+ --onto)
+ shift
+ ONTO=$(git rev-parse --verify "$1") ||
+ die "Does not point to a valid commit: $1"
+ ;;
''|-h)
usage
;;
- *)
+ --)
+ shift
+ test $# -eq 1 -o $# -eq 2 || usage
test -d "$DOTEST" &&
die "Interactive rebase already started"
@@ -620,15 +654,6 @@ do
comment_for_reflog start
- ONTO=
- case "$1" in
- --onto)
- ONTO=$(git rev-parse --verify "$2") ||
- die "Does not point to a valid commit: $2"
- shift; shift
- ;;
- esac
-
require_clean_work_tree
UPSTREAM=$(git rev-parse --verify "$1") || die "Invalid base"
--
1.5.6.167.g86f2
^ permalink raw reply related
* [PATCH 1/2] t3404: extra checks and s/! git/test_must_fail git/
From: Stephan Beyer @ 2008-06-20 18:30 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin, Christian Couder, Stephan Beyer
In-Reply-To: <alpine.DEB.1.00.0806201407230.6439@racer>
This patch adds some extra checks (especially branch checks)
test cases and changes "! git ..." into "test_must_fail git".
Also a --onto test case is added.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
---
Dscho,
as you've comman^Wwished ;-)
(except the analism)
Note that I've also added a --onto test.
t/t3404-rebase-interactive.sh | 31 ++++++++++++++++++++++++-------
1 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/t/t3404-rebase-interactive.sh b/t/t3404-rebase-interactive.sh
index e6f3fad..96985ff 100755
--- a/t/t3404-rebase-interactive.sh
+++ b/t/t3404-rebase-interactive.sh
@@ -107,6 +107,7 @@ chmod a+x fake-editor.sh
test_expect_success 'no changes are a nop' '
git rebase -i F &&
+ test "$(git symbolic-ref -q HEAD)" = "refs/heads/branch2" &&
test $(git rev-parse I) = $(git rev-parse HEAD)
'
@@ -115,14 +116,26 @@ test_expect_success 'test the [branch] option' '
git rm file6 &&
git commit -m "stop here" &&
git rebase -i F branch2 &&
+ test "$(git symbolic-ref -q HEAD)" = "refs/heads/branch2" &&
+ test $(git rev-parse I) = $(git rev-parse branch2) &&
test $(git rev-parse I) = $(git rev-parse HEAD)
'
+test_expect_success 'test --onto <branch>' '
+ git checkout -b test-onto branch2 &&
+ git rebase -i --onto branch1 F &&
+ test "$(git symbolic-ref -q HEAD)" = "refs/heads/test-onto" &&
+ test $(git rev-parse HEAD^) = $(git rev-parse branch1) &&
+ test $(git rev-parse I) = $(git rev-parse branch2)
+'
+
test_expect_success 'rebase on top of a non-conflicting commit' '
git checkout branch1 &&
git tag original-branch1 &&
git rebase -i branch2 &&
test file6 = $(git diff --name-only original-branch1) &&
+ test "$(git symbolic-ref -q HEAD)" = "refs/heads/branch1" &&
+ test $(git rev-parse I) = $(git rev-parse branch2) &&
test $(git rev-parse I) = $(git rev-parse HEAD~2)
'
@@ -155,9 +168,12 @@ EOF
test_expect_success 'stop on conflicting pick' '
git tag new-branch1 &&
- ! git rebase -i master &&
+ test_must_fail git rebase -i master &&
+ test "$(git rev-parse HEAD~3)" = "$(git rev-parse master)" &&
test_cmp expect .git/.dotest-merge/patch &&
test_cmp expect2 file1 &&
+ test "$(git-diff --name-status |
+ sed -n -e "/^U/s/^U[^a-z]*//p")" = file1 &&
test 4 = $(grep -v "^#" < .git/.dotest-merge/done | wc -l) &&
test 0 = $(grep -c "^[^#]" < .git/.dotest-merge/git-rebase-todo)
'
@@ -165,6 +181,7 @@ test_expect_success 'stop on conflicting pick' '
test_expect_success 'abort' '
git rebase --abort &&
test $(git rev-parse new-branch1) = $(git rev-parse HEAD) &&
+ test "$(git symbolic-ref -q HEAD)" = "refs/heads/branch1" &&
! test -d .git/.dotest-merge
'
@@ -331,7 +348,7 @@ test_expect_success 'interactive -t preserves tags' '
test_expect_success '--continue tries to commit' '
git checkout to-be-rebased &&
test_tick &&
- ! git rebase -i --onto new-branch1 HEAD^ &&
+ test_must_fail git rebase -i --onto new-branch1 HEAD^ &&
echo resolved > file1 &&
git add file1 &&
FAKE_COMMIT_MESSAGE="chouette!" git rebase --continue &&
@@ -342,7 +359,7 @@ test_expect_success '--continue tries to commit' '
test_expect_success 'verbose flag is heeded, even after --continue' '
git reset --hard HEAD@{1} &&
test_tick &&
- ! git rebase -v -i --onto new-branch1 HEAD^ &&
+ test_must_fail git rebase -v -i --onto new-branch1 HEAD^ &&
echo resolved > file1 &&
git add file1 &&
git rebase --continue > output &&
@@ -380,7 +397,7 @@ test_expect_success 'interrupted squash works as expected' '
! FAKE_LINES="1 squash 3 2" git rebase -i HEAD~3 &&
(echo one; echo two; echo four) > conflict &&
git add conflict &&
- ! git rebase --continue &&
+ test_must_fail git rebase --continue &&
echo resolved > conflict &&
git add conflict &&
git rebase --continue &&
@@ -398,10 +415,10 @@ test_expect_success 'interrupted squash works as expected (case 2)' '
! FAKE_LINES="3 squash 1 2" git rebase -i HEAD~3 &&
(echo one; echo four) > conflict &&
git add conflict &&
- ! git rebase --continue &&
+ test_must_fail git rebase --continue &&
(echo one; echo two; echo four) > conflict &&
git add conflict &&
- ! git rebase --continue &&
+ test_must_fail git rebase --continue &&
echo resolved > conflict &&
git add conflict &&
git rebase --continue &&
@@ -449,7 +466,7 @@ test_expect_success 'rebase a commit violating pre-commit' '
chmod a+x $PRE_COMMIT &&
echo "monde! " >> file1 &&
test_tick &&
- ! git commit -m doesnt-verify file1 &&
+ test_must_fail git commit -m doesnt-verify file1 &&
git commit -m doesnt-verify --no-verify file1 &&
test_tick &&
FAKE_LINES=2 git rebase -i HEAD~2
--
1.5.6.167.g86f2
^ permalink raw reply related
* Re: [WIP/PATCH v3] gitweb: add test suite with Test::WWW::Mechanize::CGI
From: Jakub Narebski @ 2008-06-20 18:03 UTC (permalink / raw)
To: Lea Wiemann; +Cc: git
In-Reply-To: <485BB578.3040605@gmail.com>
On Fri, 20 Jun 2008, Lea Wiemann wrote:
> Jakub Narebski wrote:
>>
>> Second, I think it would be better if adding XML checks (RSS, Atom,
>> OPML) would be left as separate commit.
>
> Sure; FWIW I'm generally in favor of having a large initial commit for
> new independent files [...]
I just think that having this separate could help bisectability in
the case of errors.
>>> +# set up test repository
>>
>> I have created this part as a copy of older t9500 gitweb test, thinking
>> about what we might want to test, but the WIP of Mechanize based t9503
>> doesn't have yet tests for those specific features.
>
> I was thinking about that. Right now the tests are so generic that you
> can replace the test repository with anything else as long as it has
> some commits (and later some tags, etc.). That's kinda nice.
Well, I've tried to put the cases where something can go wrong, and to
cover wide range of possibilities. Rename, copy, typechange, merge
commit for testing *diff views, symlink to test 'tree' view, different
types of tags and tagged objects...
What could be added is different types of stage output: filenames with
'*', '+', '=', ':', '?', whitespace, etc. Checking if submodules
doesn't trip gitweb would be good idea too.
> I'm generally not in favor of maintaining any test count plans; they're
> an unnecessary failure source, and I don't think they buy us much, if
> anything -- correct me if I'm missing something Perl-specific here.
While they can detect otherwise unnoticed errors, I think most of time
they are error in test counting... so I can agree with that.
>> Why do you use shortened SHA1 identifier, instead of full SHA1?
>> Links in gitweb use full SHA1.
>
> That's for readability in the test output; links get checked anyway,
> don't they? If you think we should be testing against full SHA1s,
> that's fine too.
This would reduce number of operations when crawling gitweb output.
[about workaround bug in TWM::CGI when path to application contains
embedded space].
> ISTR that using cgi(sub ...) gives us problems with untrappable exits in
> gitweb.cgi (and possibly more things), right?
Actually ->cgi_application(<path>) is implemented using ->cgi(<sub>)
in TWM::CGI. The bug is that it uses straight "system($application)",
without any quoting, after ensuring that $application is absolute path
(so quoting it beforehand won't work).
> I'm fine with the workarounds we have in place, they don't seem brittle.
They work around the fact that we use 'trash directory', but they
would fail if you run test from the directory which contains spaces,
for example "/home/Lea Wiemann/git/t" (I think this has greater
probability happening on operating systems other than Linux, for
example MS Windows with "My Documents" or "Program Files").
>>> +our $baseurl = "http://localhost";
>>> +our($params, $url, $pagedesc, $status);
>>
>> I think we can use 'my' here;
>
> They're used in subroutines, so I believe 'our' is correct here.
Actually 'my' would work here too; the problem with gitweb being
forced to use 'our' to make it work with mod_perl isn't about the
fact that they are global variables, but with initializing them,
as mod_perl wraps whole gitweb in a block (processing requests).
>> As to the rest of the test: I think as preliminary test it is a good
>> thing to have. We can think about what tests to add later (unless you
>> rather have exhaustive test suite now...).
>
> I'll be writing tests as I go and change parts of gitweb. I won't be
> able to write exhaustive tests, but I at least want to make sure that
> the code I'm changing is covered somehow.
Write test when we notice something breaking seems a common theme
in git development... ;-)
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] graph.c: make many functions static
From: Adam Simpkins @ 2008-06-20 17:19 UTC (permalink / raw)
To: Junio C Hamano
Cc: しらいしななこ, git
In-Reply-To: <7vmylgo8v7.fsf@gitster.siamese.dyndns.org>
On Fri, Jun 20, 2008 at 12:37:00AM -0700, Junio C Hamano wrote:
> Adam Simpkins <adam@adamsimpkins.net> writes:
>
> > On Thu, Jun 19, 2008 at 12:16:11PM -0700, Junio C Hamano wrote:
> >> しらいしななこ <nanako3@lavabit.com> writes:
> > ...
> >> > +/* Internal API */
> >> > + ...
> >> > +static int graph_next_line(struct git_graph *graph, struct strbuf *sb);
> >> > +static void graph_padding_line(struct git_graph *graph, struct strbuf *sb);
> >> > +static void graph_show_strbuf(struct git_graph *graph, struct strbuf const *sb);
> >>
> >> I think these are probably fine, not in the sense that nobody calls these
> >> functions _right now_ but in the sense that I do not foresee a calling
> >> sequence outside the graph.c internal that needs to call these directly,
> >> instead of calling graph_show_*() functions that use these.
> >
> > Documentation/technical/api-history-graph.txt should also be updated
> > to remove the discussion of these functions if they are no longer
> > publicly exposed.
>
> Actually, I was expecting (not necessarily _hoping_) you to defend these
> public API by providing examples that illustrates when calling these from
> outside graph API implementation could be useful.
Ah. I see :-)
I do think that graph_next_line() and graph_padding_line() are
potentially useful as public APIs, since they are more generic than
the other API functions that wrap them. These functions both output
to a strbuf. graph_show_oneline() and graph_show_padding() are simple
wrappers around these functions that print the resulting strbuf to
stdout. graph_next_line() and graph_padding_line() will be needed by
anyone who wants to write the graph output somewhere other than
stdout. They could also be useful if someone wants to further
manipulate the output before printing it.
graph_show_strbuf() is a somewhat similar situation.
graph_show_commit_msg() is a wrapper around graph_show_strbuf()--it
calls graph_show_strbuf() and then also prints the remainder of the
graph. A caller would need to use graph_show_strbuf() directly if
they have multiple strbufs that need to be displayed alongside the
graph. In this case, they'll want to call graph_show_strbuf()
multiple times before printing the remainder of the graph. (The
caller could also work around this by concatenating the strbufs first,
then passing the entire thing to graph_show_commit_msg(). However,
the downside of this approach is that it requires copying the
strbufs.)
I didn't defend these earlier since I wasn't sure if it was simply
git's style to make functions static until there is a proven need for
them to be public. At the moment, the existing log-tree.c code is
only using the wrappers around these functions. I don't really see an
immediate need for the core git code to use any of these functions
directly, but they might of interest to people working on libifying
git.
--
Adam Simpkins
adam@adamsimpkins.net
^ permalink raw reply
* Re: Are C++ contributions welcome?
From: Jose María Gómez Vergara @ 2008-06-20 16:45 UTC (permalink / raw)
To: David Kastrup; +Cc: git
In-Reply-To: <86skv81356.fsf@lola.quinscape.zz>
look nice
On Friday 20 June 2008 18:29:09 David Kastrup wrote:
> Jose María Gómez Vergara <josemaria@jmgv.org> writes:
> > Before starting, do you have any preference for Qt or Gtk in Git. I feel
> > quite confortable with both of them.
> >
> > Qt . C++ GPL
> > Gtk+. C - LGPL
> >
> > The quality is good for both of them
>
> Please take a look at
> <URL:http://developer.imendio.com/projects/giggle>. It might be
> worthwhile not to start from scratch here.
^ permalink raw reply
* Re: Wither git-cheetah?
From: Johannes Schindelin @ 2008-06-20 16:43 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90806200853w481f4e59idb4777dfce96b5d5@mail.gmail.com>
Hi,
On Fri, 20 Jun 2008, Martin Langhoff wrote:
> Is anyone working on git-cheetah? What I thougtht at the time was a
> joke from Johannes Schindelin (below) turned out to be a real "I'll
> stop work now" thing.
>
> Moodle.org is now seriously considering a move to GIT, and a
> Tortoise-ish UI would be a good crutch for the transition. Anyone
> played with TortoiseHg? http://tortoisehg.sourceforge.net/
We had a brilliant application to work on Git-Cheetah for non-Win32
systems. Unfortunately, another project snatched that student, but we
were scarce on GSoC slots anyway.
This would have been very nice for me, as I almost exclusively work on
Linux these days. And I finally grasped the concept of "scratching your
own itch".
So no, I have almost no intention on continuing to work on Git-Cheetah on
Windows.
Having said that, we had a contributor who seemed to be quite willing to
continue working on Git-Cheetah, as can be seen from the commit history.
However, I have the impression that my comments on his patches put him off
somewhat, even if I really liked his work.
Ciao,
Dscho
^ permalink raw reply
* Re: Are C++ contributions welcome?
From: Barry Roberts @ 2008-06-20 16:40 UTC (permalink / raw)
To: Martin Langhoff; +Cc: jose maria gomez vergara, git
In-Reply-To: <46a038f90806200859r520d0593q367d6625a240595a@mail.gmail.com>
Martin Langhoff wrote:
> if you have UI/Win32 experience, a good friendly UI for newcomers to
> GIT is something we are lacking.
>
My assessment of git-cola (formerly ugit) makes me wonder if that
statement is still true. It doesn't have explorer integration,
and the install is tedious on windows. But since it uses Qt4
it's purty enough for Windows users and it uses porcelain
commands so it doesn't require plumbing knowledge.
The Windows users that I've shown git cola are universally
excited to try it. And my dogfood'ing on Linux has been going
well.
FWIW,
Barry Roberts
^ permalink raw reply
* Re: Are C++ contributions welcome?
From: Raimund Bauer @ 2008-06-20 16:38 UTC (permalink / raw)
To: Jose María Gómez Vergara; +Cc: git
In-Reply-To: <200806201820.54585.josemaria@jmgv.org>
On Fri, 2008-06-20 at 18:20 +0200, Jose María Gómez Vergara wrote:
> Before starting, do you have any preference for Qt or Gtk in Git. I feel quite
> confortable with both of them.
>
> Qt . C++ GPL
> Gtk+. C - LGPL
If you think about using one of those 2 you might also want to take a
look at
qgit - http://sourceforge.net/projects/qgit/ (qt)
and
giggle - http://developer.imendio.com/projects/giggle/ (gtk)
Not sure if those toolkits can for used to produce a TortoiseGit.
best regards,
Ray
^ permalink raw reply
* Re: Are C++ contributions welcome?
From: David Kastrup @ 2008-06-20 16:29 UTC (permalink / raw)
To: git
In-Reply-To: <200806201820.54585.josemaria@jmgv.org>
Jose María Gómez Vergara <josemaria@jmgv.org> writes:
> Before starting, do you have any preference for Qt or Gtk in Git. I feel quite
> confortable with both of them.
>
> Qt . C++ GPL
> Gtk+. C - LGPL
>
> The quality is good for both of them
Please take a look at
<URL:http://developer.imendio.com/projects/giggle>. It might be
worthwhile not to start from scratch here.
--
David Kastrup
^ permalink raw reply
* Re: Are C++ contributions welcome?
From: Jose María Gómez Vergara @ 2008-06-20 16:20 UTC (permalink / raw)
To: git
In-Reply-To: <200806201811.01444.josemaria@jmgv.org>
Before starting, do you have any preference for Qt or Gtk in Git. I feel quite
confortable with both of them.
Qt . C++ GPL
Gtk+. C - LGPL
The quality is good for both of them
On Friday 20 June 2008 18:11:01 Jose María Gómez Vergara wrote:
> Good that is a really good news because I really like doing front-ends and
> GUI applications. I will take care of this.
>
> On Friday 20 June 2008 17:59:09 Martin Langhoff wrote:
> > On Fri, Jun 20, 2008 at 9:03 AM, Johannes Schindelin
> >
> > <Johannes.Schindelin@gmx.de> wrote:
> > >> I don't feel comfortable programing in C and I prefer C++ only because
> > >> I have more experience using this one. May I contribute to this
> > >> project in that language?.
> >
> > if you have UI/Win32 experience, a good friendly UI for newcomers to
> > GIT is something we are lacking. Johannes got started with git-cheetah
> > a while ago, and there is a similar project called TortoiseHg, either
> > might be a good starting point.
> >
> > As Jakub noted, C++ is a reasonably good fit for UIs, and we are
> > lacking those. We have a fantastic team of people doing C work on the
> > core of git, and noone on GUIs. So I'd say yes, C++/UI help is
> > something we need 'round here :-)
> >
> > cheers,
> >
> >
> >
> > m
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Are C++ contributions welcome?
From: Jose María Gómez Vergara @ 2008-06-20 16:11 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Johannes Schindelin, git
In-Reply-To: <46a038f90806200859r520d0593q367d6625a240595a@mail.gmail.com>
Good that is a really good news because I really like doing front-ends and GUI
applications. I will take care of this.
On Friday 20 June 2008 17:59:09 Martin Langhoff wrote:
> On Fri, Jun 20, 2008 at 9:03 AM, Johannes Schindelin
>
> <Johannes.Schindelin@gmx.de> wrote:
> >> I don't feel comfortable programing in C and I prefer C++ only because I
> >> have more experience using this one. May I contribute to this project in
> >> that language?.
>
> if you have UI/Win32 experience, a good friendly UI for newcomers to
> GIT is something we are lacking. Johannes got started with git-cheetah
> a while ago, and there is a similar project called TortoiseHg, either
> might be a good starting point.
>
> As Jakub noted, C++ is a reasonably good fit for UIs, and we are
> lacking those. We have a fantastic team of people doing C work on the
> core of git, and noone on GUIs. So I'd say yes, C++/UI help is
> something we need 'round here :-)
>
> cheers,
>
>
>
> m
^ permalink raw reply
* Is git-imap-send able to use SSL?
From: Cristian Peraferrer @ 2008-06-20 16:08 UTC (permalink / raw)
To: git
I am trying to use git-imap-send to send a Draft to my GMail account
which uses SSL to connect, I have put the correct port (993 in that
case) in the config file but it seems it doesn't work. I figure that
git-imap-send is not able to connect using SSL.
--
Cristian Peraferrer
Jabber ID: corellian at swissjabber.ch
^ permalink raw reply
* Re: Are C++ contributions welcome?
From: Martin Langhoff @ 2008-06-20 15:59 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: jose maria gomez vergara, git
In-Reply-To: <alpine.DEB.1.00.0806201400550.6439@racer>
On Fri, Jun 20, 2008 at 9:03 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
>> I don't feel comfortable programing in C and I prefer C++ only because I
>> have more experience using this one. May I contribute to this project in
>> that language?.
if you have UI/Win32 experience, a good friendly UI for newcomers to
GIT is something we are lacking. Johannes got started with git-cheetah
a while ago, and there is a similar project called TortoiseHg, either
might be a good starting point.
As Jakub noted, C++ is a reasonably good fit for UIs, and we are
lacking those. We have a fantastic team of people doing C work on the
core of git, and noone on GUIs. So I'd say yes, C++/UI help is
something we need 'round here :-)
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* [PATCH] Added the printing of 'errno' error number when the attempt to open the COMMIT_EDITMSG file is failed
From: Cristian Peraferrer @ 2008-06-20 15:55 UTC (permalink / raw)
To: Junio C Hamano, git
From: Cristian Peraferrer <corellian.c@gmail.com>
Date: Fri, 20 Jun 2008 17:24:20 +0200
Subject: [PATCH] Added the printing of 'errno' error number when the
attempt to open the COMMIT_EDITMSG file is failed
Now when the COMMIT_EDITMSG cannot be opened, the die message gives
more information to the user by giving the 'errno' number.
Signed-off-by: Cristian Peraferrer <corellian.c@gmail.com>
---
builtin-commit.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index 90200ed..a33f43a 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -502,7 +502,8 @@ static int prepare_to_commit(const char
*index_file, const char *prefix)
fp = fopen(git_path(commit_editmsg), "w");
if (fp == NULL)
- die("could not open %s", git_path(commit_editmsg));
+ die("could not open %s: %s",
+ git_path(commit_editmsg), strerror(errno));
if (cleanup_mode != CLEANUP_NONE)
stripspace(&sb, 0);
--
1.5.5
^ permalink raw reply related
* Re: Are C++ contributions welcome?
From: Jose María Gómez Vergara @ 2008-06-20 15:54 UTC (permalink / raw)
To: sverre; +Cc: git
In-Reply-To: <bd6139dc0806200830h633c954bn6dbfc87ada90756b@mail.gmail.com>
To be honest, I like a lot projects made in C. I have been working with Qt and
with Gtk and I must say that it is easy for me to understand Gtk that is in C
than Qt that is in C++. Something I feel like if C++ design do unnecessary
abstration. The thing is that due to my job, I am more familiar with C++
since the project in which I work at my job is a really big monster that
seems to be easier to manage using an a litter high level language as C++
instead C.
I would like to learn more C, but sometime I think I should focus in one
language and learn as much as possible about it.
Sometime ago I had to decide between C and C++. Looking around my city, it was
easy to find a good job working for a big mega-application that for a small
system application. It doesn't mean I like more working in high-level but C++
seems to have the best of both worlds.
I will try to do things in C...
Btw, more than strings I miss STL containers and algorithmits, but, if I want
to join to contribute I know I must adapt myself to the rules. So, i will try
to do thing in C.
Thanks
On Friday 20 June 2008 17:30:31 Sverre Rabbelier wrote:
> On Fri, Jun 20, 2008 at 2:23 PM, jose maria gomez vergara
>
> <josemaria@jmgv.org> wrote:
> > I don't feel comfortable programing in C and I prefer C++ only because I
> > have more experience using this one. May I contribute to this project in
> > that language?.
>
> Any programmer can learn a new language as long as they have enough
> programming skills; it's not the language you are proficient in, it is
> the programming you are proficient in. If you would like to contribute
> to git, consider polishing up your C, really it is not all that hard
> ;). The main thing you will probably stumble into is the lack of
> std::string, but there are plenty examples in the git codebase to
> learn how git handles string.
^ permalink raw reply
* Wither git-cheetah?
From: Martin Langhoff @ 2008-06-20 15:53 UTC (permalink / raw)
To: git
Is anyone working on git-cheetah? What I thougtht at the time was a
joke from Johannes Schindelin (below) turned out to be a real "I'll
stop work now" thing.
Moodle.org is now seriously considering a move to GIT, and a
Tortoise-ish UI would be a good crutch for the transition. Anyone
played with TortoiseHg? http://tortoisehg.sourceforge.net/
On Fri, Apr 11, 2008 at 2:00 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Fri, 11 Apr 2008, John Goerzen wrote:
>> Think about it this way: once the Windows stuff for Git gets mature (to
>> the TortoiseGit level), there are going to be a lot of people using Git
>> that really *can't* operate a mail client because the only "mail client"
>> at their disposal is Outlook.
> That's a scary thought. I will stop all my work on git-cheetah.
cheers,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: [q] git-diff --reverse 7def2be1..7def2be1^
From: Ingo Molnar @ 2008-06-20 15:38 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Matthieu Moy, git
In-Reply-To: <20080620153819.GF17373@elte.hu>
* Jakub Narebski <jnareb@gmail.com> wrote:
> > hm, can Bash be taught to do command completion on 'git rer<tab>',
> > like it is able to do on git-rer<tab> ?
>
> contrib/completion/git-completion.bash in git repository.
works perfectly - thanks for the suggestion!
Ingo
^ permalink raw reply
* Re: Are C++ contributions welcome?
From: Sverre Rabbelier @ 2008-06-20 15:30 UTC (permalink / raw)
To: jose maria gomez vergara; +Cc: git
In-Reply-To: <4c88165dd0077363a30b4f98fed16c2f@localhost>
On Fri, Jun 20, 2008 at 2:23 PM, jose maria gomez vergara
<josemaria@jmgv.org> wrote:
> I don't feel comfortable programing in C and I prefer C++ only because I
> have more experience using this one. May I contribute to this project in
> that language?.
Any programmer can learn a new language as long as they have enough
programming skills; it's not the language you are proficient in, it is
the programming you are proficient in. If you would like to contribute
to git, consider polishing up your C, really it is not all that hard
;). The main thing you will probably stumble into is the lack of
std::string, but there are plenty examples in the git codebase to
learn how git handles string.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] git-gui: Fix accidental staged state toggle when clicking top pixel row
From: Johannes Sixt @ 2008-06-20 15:26 UTC (permalink / raw)
To: Richard Quirk; +Cc: git, spearce
In-Reply-To: <1213973895-10264-1-git-send-email-richard.quirk@gmail.com>
Richard Quirk schrieb:
> If a text widget is asked the index at x,y with y == 0 or y == 1 it will
> always return 1.0 as the nearest index, regardless of the x position.
>
> This means that clicking the top 2 pixels of the Unstaged/Staged Changes
> lists caused the state of the file there to be toggled. This patch
> checks that the pixel clicked is greater than 1, so there is less chance
> of accidentally staging or unstaging changes.
Ah, that would explain why it sometimes happened that a file was staged
even though the mouse pointer was no where near the icon!
-- Hannes
^ permalink raw reply
* [PATCH] git-gui: Fix accidental staged state toggle when clicking top pixel row
From: Richard Quirk @ 2008-06-20 14:58 UTC (permalink / raw)
To: git; +Cc: spearce, Richard Quirk
If a text widget is asked the index at x,y with y == 0 or y == 1 it will
always return 1.0 as the nearest index, regardless of the x position.
This means that clicking the top 2 pixels of the Unstaged/Staged Changes
lists caused the state of the file there to be toggled. This patch
checks that the pixel clicked is greater than 1, so there is less chance
of accidentally staging or unstaging changes.
Signed-off-by: Richard Quirk <richard.quirk@gmail.com>
---
To test the unpatched changes, make a change in a git-controlled repo and run
git-gui. Click the Unstaged Changes list away from the first column, but near
(within 1 pixel) to the pink header part. The file underneath is staged, rather
surprisingly. Similarly, for staged files click a pixel or 2 underneath the
green Staged Changes header and the changes are unstaged, even if the first
column is not clicked.
This change looks like a hack - but I'm pretty sure it's a bug in the Tk text
widget that's causing the strange behaviour. I couldn't see any other way to
fix this accidental (un)staging, which seems to get me at least once a day
lately.
git-gui.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-gui.sh b/git-gui.sh
index 23d7dfe..980dc0b 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -1797,7 +1797,7 @@ proc toggle_or_diff {w x y} {
$ui_index tag remove in_sel 0.0 end
$ui_workdir tag remove in_sel 0.0 end
- if {$col == 0} {
+ if {$col == 0 && $y > 1} {
set i [expr {$lno-1}]
set ll [expr {[llength $file_lists($w)]-1}]
--
1.5.6.9.g26943
^ permalink raw reply related
* Re: [q] git-diff --reverse 7def2be1..7def2be1^
From: Jakub Narebski @ 2008-06-20 14:23 UTC (permalink / raw)
To: Ingo Molnar; +Cc: Matthieu Moy, git
In-Reply-To: <20080620135004.GB8135@elte.hu>
Ingo Molnar <mingo@elte.hu> writes:
> * Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
>
> > (BTW, git-foo is being obsoleted in favor of "git foo")
>
> hm, can Bash be taught to do command completion on 'git rer<tab>', like
> it is able to do on git-rer<tab> ?
contrib/completion/git-completion.bash in git repository.
I don't know if there are some ready packages[1] for contrib stuff, and
git-completion.bash doesn't seem to get packaged with git.
[1] RPM packages, because Debian seems to have packaged everything, or
almist everything, in a itty-bitty-tiny package(lets) :-P
You can always use zsh, which has git completion in package... ;-)
> Ingo
--
Jakub Narebski
"My name is Inigo Montoya. You killed my father prepare to die"
(The Princess Bride)
^ permalink raw reply
* Re: Are C++ contributions welcome?
From: Jakub Narebski @ 2008-06-20 14:16 UTC (permalink / raw)
To: jose maria gomez vergara; +Cc: git
In-Reply-To: <4c88165dd0077363a30b4f98fed16c2f@localhost>
Jose Maria Gomez Vergara <josemaria@jmgv.org> writes:
> I think Git is a really good project and I would like to contribute to it.
> I have been having a look to the source and I have realized on that all
> code is C (well and Perl for some scripts and so..). I know that C++ code
> was not welcome sometime ago, but I don't know if this have changed.
>
> I don't feel comfortable programing in C and I prefer C++ only because I
> have more experience using this one. May I contribute to this project in
> that language?.
I don't think that C++ would get accepted because it would introduce
another dependency; if not runtime dependency (libstdc++), then build
requirement (C++ compiler).
And I think it doesn't bring much: git is not some GUI application
where OOP works best; it is 'close to the metal' (performance), where
I think C works best.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [q] git-diff --reverse 7def2be1..7def2be1^
From: Ingo Molnar @ 2008-06-20 13:52 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3d4mcmq20.fsf@localhost.localdomain>
* Jakub Narebski <jnareb@gmail.com> wrote:
> > But Git didnt recognize that as a valid commit range.
>
> There is shortcut for rev^..rev, namely rev^! (I'm not sure if it is
> documented anywhere, though), so you could have used
>
> git diff 7def2be1^!
nice! :-)
> > [ time passes as i read the manpage - the final thing i do when
> > every other measure fails ;-) ]
> >
> > Ah, there's "git-log -R" that would achieve this.
>
> I think you should have done this first...
to read the man page? Nobody reads the manuals, except in grave
circumstances ;-)
(Seriously, i usually try to guess around a lot with shell commands just
to figure out new things, and to see how intuitive they are.)
Ingo
^ permalink raw reply
* Re: [q] git-diff --reverse 7def2be1..7def2be1^
From: Ingo Molnar @ 2008-06-20 13:50 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqiqw42vk6.fsf@bauges.imag.fr>
* Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> (BTW, git-foo is being obsoleted in favor of "git foo")
hm, can Bash be taught to do command completion on 'git rer<tab>', like
it is able to do on git-rer<tab> ?
Ingo
^ permalink raw reply
* Re: [WIP/PATCH v3] gitweb: add test suite with Test::WWW::Mechanize::CGI
From: Lea Wiemann @ 2008-06-20 13:49 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200806201408.05254.jnareb@gmail.com>
Jakub Narebski wrote:
> First, it is not XML validation[*1*], but check if XML is well-formed.
> Second, I think it would be better if adding XML checks (RSS, Atom,
> OPML) would be left as separate commit.
Sure; FWIW I'm generally in favor of having a large initial commit for
new independent files (and since we don't need to worry about conflicts
I'm not fervent about getting this into the next branch ASAP), but we
can definitely add XML checking separately.
>> +# set up test repository
>
> I have created this part as a copy of older t9500 gitweb test, thinking
> about what we might want to test, but the WIP of Mechanize based t9503
> doesn't have yet tests for those specific features.
I was thinking about that. Right now the tests are so generic that you
can replace the test repository with anything else as long as it has
some commits (and later some tags, etc.). That's kinda nice.
>> +# We don't count properly when skipping, so no_plan is necessary.
>> +use Test::More qw(no_plan);
>
> Actually it is not that we cannot could properly when skipping, because
> there are two ways to have skipped tests and test count upfront,
We're skipping tests if a page-load fails to prevent a slew of failure,
using constructs like if(test_page '?...') { ... inspect the page ...}.
It's my impression that we shouldn't end up with a wrong test count even
if one test fails; but then we'd have to replace those ifs with
cumbersome skip blocks.
I'm generally not in favor of maintaining any test count plans; they're
an unnecessary failure source, and I don't think they buy us much, if
anything -- correct me if I'm missing something Perl-specific here.
> Why do you use shortened SHA1 identifier, instead of full SHA1?
> Links in gitweb use full SHA1.
That's for readability in the test output; links get checked anyway,
don't they? If you think we should be testing against full SHA1s,
that's fine too.
> Errr, HEAD would be $revisions[0], $revisions[-1] would be $root.
Fixed, thanks.
> Another solution would be to copy relevant parts of cgi_application
> (without all the checks for example), and use $mech->cgi( sub { ... } );
> here (without the cgi_application bug).
ISTR that using cgi(sub ...) gives us problems with untrappable exits in
gitweb.cgi (and possibly more things), right? I'm fine with the
workarounds we have in place, they don't seem brittle.
>> +our $baseurl = "http://localhost";
>> +our($params, $url, $pagedesc, $status);
>
> I think we can use 'my' here;
They're used in subroutines, so I believe 'our' is correct here.
> Style: I would write "our (", with space [...]
>> +# if (test_page '?p=.git;a=summary', 'repository summary') {
>
> Style: I would use function call form, i.e. "test_page(...)", not
> command-like (or script-like) form.
Both fixed, thanks.
> As to the rest of the test: I think as preliminary test it is a good
> thing to have. We can think about what tests to add later (unless you
> rather have exhaustive test suite now...).
I'll be writing tests as I go and change parts of gitweb. I won't be
able to write exhaustive tests, but I at least want to make sure that
the code I'm changing is covered somehow.
-- Lea
^ permalink raw reply
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