* Re: [PATCH] Mac OS X 10.5 does not require the OLD_ICONV flag set
From: David Symonds @ 2007-11-02 11:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Blake Ramsdell, git
In-Reply-To: <7vbqad3pjw.fsf@gitster.siamese.dyndns.org>
On 11/2/07, Junio C Hamano <gitster@pobox.com> wrote:
> "David Symonds" <dsymonds@gmail.com> writes:
>
> > Further, that comparison is going to fail as soon as the next revision
> > of Darwin (9.0.1, etc.) is released.
>
> Can we do something intelligent with $(shell iconv --version)
> there instead, I wonder, then?
It would probably be most appropriate for the autoconf script. Now
that I look at configure.ac, there's already a test for iconv in
there; is it not used?
Dave.
^ permalink raw reply
* Re: Where man git-format-patch sends me?
From: Sergei Organov @ 2007-11-02 11:25 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Johannes Schindelin, git
In-Reply-To: <2A9EA819-C27A-4538-A9ED-B5281D137B94@wincent.com>
Wincent Colaiuta <win@wincent.com> writes:
> El 1/11/2007, a las 16:47, Sergei Organov escribió:
>
>> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>>
>>> Hi,
>>>
>>> On Thu, 1 Nov 2007, Sergei Organov wrote:
>>>
>>>> $ man git-format-patch
>>>> [...]
>>>> OPTIONS
>>>> -p Generate patch (see section on generating patches)
>>>>
>>>> -u Synonym for "-p".
>>>
>>> As you can easily see from Documentation/git-format-patch.txt, this
>>> part
>>> is generated from the file Documentation/diff-options.txt.
>>
>> Sorry, I did saw that, but it doesn't change anything.
>>
>> 1. As a user reading man git-format-patch, where do I find this
>> "section
>> on generating patches"? In another man-page? In the html
>> documentation? On the moon?
>>
>> 2. I can't find "section on generating patches" in the man git-diff
>> either, and I did say this in the part of my original message you've
>> snipped.
>>
>> So the main question remains: could you please point me to the exact
>> place in 'Documentation/' directory where this "section on generating
>> patches" resides?
>
> I believe the section in question is in Documentation/diff-format.txt
Ah, thank you! Now, diff-format.txt is included by
git-diff-index/git-diff-files/git-diff-tree, but not by git-diff and
git-format-patch. Do you think it is the right thing for the latter two
to include diff-format as well?
--
Sergei.
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Steffen Prohaska @ 2007-11-02 11:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andreas Ericsson, git
In-Reply-To: <7v7il13p1g.fsf@gitster.siamese.dyndns.org>
On Nov 2, 2007, at 11:44 AM, Junio C Hamano wrote:
> Steffen Prohaska <prohaska@zib.de> writes:
>
>> - in a workflow that is base on shared branches (CVS-style),
>> ...
>> In addition push should push back to the remote branch a local
>> topic was originally branched off.
>
> Why? If it is shared, and if you are shooting for the simplest
> set of commands, wouldn't you work this way?
Yes. I would work exactly this way with current git.
> $ git clone $public my-work-dir
> $ cd my-work-dir
> $ git checkout -b --track foo origin/foo
So the implicit rule here is
"name a branch identical in all repositories you're dealing with"
right?
That is foo is named foo at the remote, named foo as a tracking
branch (git handles this automatically) and is named foo as your
local branch.
I believe it is reasonable. Though I have two questions:
1) If this is best practice, why doesn't save git me from typos?
Why do I need to type "foo" correctly twice?
2) What shall I do if I am dealing with more than one shared
repository? Andreas' group should already run into problems
here. They have several shared repos and if they want to
checkout several local branches from different repos they
need to somehow encode the name of the remote in the name
of the local branch.
> $ hack hack hack, commit, commit, commit *on* *foo*
> $ git push $public foo
>
> I think the recent git defaults to --track anyway so the third
> step do not spell out --track.
It does.
> With your "remote.$public.push = HEAD", the last step would be
> "git push" without any parameter.
Indeed. Or with my "branch.$name.push" it would just be "git push"
as well. And I'd be probably happy then.
> If you do use private topics, then the story would change this
> way:
>
> $ git checkout -b --track foo origin/foo
> $ git checkout -b topic1 foo ;# or origin/foo
I'd be more happy without 'or'. I really want to give a single
recommendation.
So the question here is: Should I branch off the local branch or
should I branch off the remote branch? When should I do what?
What is best practice and what is used for 'exceptional'
situations?
> $ hack hack hack, commit, commit, commit on topic1
> $ git checkout -b topic2 foo ;# or origin/foo
> $ hack hack hack, commit, commit, commit on topic2
> $ git checkout foo
> $ git merge topic1
> $ test test test; # test _your_ changes
> $ git merge topic2
> $ test test test; # test _your_ changes
> $ git push ;# again push 'foo' out
This focuses testing on the integration of topic1 with topic2.
You could as well do the following
$ git checkout -b topic1 origin/foo
$ hack ...
$ git checkout -b topic2 origin/foo
$ hack ..
[ later ]
$ git checkout topic1
$ git pull # or git fetch; git rebase origin/foo
$ test test test
$ git push origin topic1:origin/foo
[ later ]
$ git checkout topic2
$ git pull # or git fetch; git rebase origin/foo
$ test test test
$ git push origin topic2:origin/foo
With my "branch.$name.push" it would just be "git push" here.
This workflow focuses testing on the integration of each of your
topics with the new changes on the shared branch independently
of your other topic.
You're done at this point. No need to merge a second time,
no need to reset branches.
It's probably a good idea to delete your local branches
now. And there is one minor question related to that: Where
to park your HEAD if you want to clean up _all_ of your local
branches because you have nothing left to do? Everything is
on the shared remote branch. The only thing you're interested
now is to checkout new changes from the shared branch if
interesting work was done by others.
> This may fail to fast forward. You may at this time want to
> "git fetch" first, rebase topic1 or topic2 that conflict with
> the other side on top of updated origin/foo, rebuild foo and
> push the result out, like this:
Or you could just pull
[ this continues Junio's example from above, you are on branch foo. ]
$ git pull
$ test test; # test of your integration of topic1, topic2
# with the new changes on the shared branch
$ git push
> $ git fetch
> $ git rebase origin/foo topic1
> $ git branch -f foo origin/foo
Here is another interesting point.
Would you recommend "git branch -f foo origin/foo" over
"git checkout foo; git reset --hard origin/foo"? I think the
first command is safer because it doesn't throw away uncommitted
changes. However it fails if you are already on branch foo. Then it
says "fatal: Cannot force update the current branch.". It is not
very intuitive if I'd ask users to first leave the branch they
want to modify, only to be able to use "git branch". "git reset"
always lets you achieve your goal. (BTW, I don't recommend having
local changes while doing integration testing ... but who knows
maybe someone feels comfortable with it.)
> $ git checkout foo
> $ git merge topic1
> $ git merge topic2
> $ test test test
> $ git push
Using rebase requires more commands than using pull, and more
intrusive commands like "branch -f" or "reset --hard" are involved.
That doesn't mean that you should not use rebase. But it certainly
needs more explanation.
Another related question is the following: After some time the
user decides that some help on topic1 would be appreciated and
another developer promises to help. So they agree to work on
a shared branch name topic1. The first developer starts with
$ git push origin topic1
From now on he _MUST NOT_ use rebase any longer! So starting
to work on the topic with a second developer completely changed
the best practice. From now no rebase is forbidden, which was
best practice before.
So the question for me is: do I want to teach developer a pull
or a rebase workflow first? Currently I believe pull will be
safer for them, better supported by git, and there will be
situations they must use pull. If the only nuisance are loops
in the history when viewing them in gitk, I'm happy to accept
this.
>> ... This makes the need for
>> pushing to a branch named differently on the remote side more
>> likely than in a pull-oriented workflow,
>
> So I do not understand this remark.
Yeah, I should have added some explanation here. I had Andreas'
200-local-branches and the topic1/topic2 example in mind that
does the integration against the shared branch.
Steffen
^ permalink raw reply
* Re: [PATCH 1/2] War on whitespace: first, a bit of retreat.
From: David Symonds @ 2007-11-02 11:50 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git, Brian Downing
In-Reply-To: <472AFFE4.9060004@op5.se>
On 11/2/07, Andreas Ericsson <ae@op5.se> wrote:
> David Symonds wrote:
> > On 11/2/07, Junio C Hamano <gitster@pobox.com> wrote:
> >> This introduces core.whitespace configuration variable that lets
> >> you specify the definition of "whitespace error".
> >>
> >> Currently there are two kinds of whitespace errors defined:
> >>
> >> * trailing-space: trailing whitespaces at the end of the line.
> >>
> >> * space-before-tab: a SP appears immediately before HT in the
> >> indent part of the line.
> >
> >> [core]
> >> whitespace = -trailing-space
> >
> > Could I suggest naming the option 'whitespaceError', so it's clearer
> > that it's a negative setting?
> >
>
> Which would also open the window for "WhitespaceWarning" and "WhitespaceAutofix"
> later on, using the same semantics.
Maybe cut straight to the chase:
[core]
whitespace.trailing = error
whitespace.space-before-tab = error
whitespace.8-spaces = warn
There'd be at least "error", "warn"; "okay" and "autofix" would be
other sensible values. I'm willing to help code this up if this sounds
good.
Dave.
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Johannes Schindelin @ 2007-11-02 12:14 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: Junio C Hamano, Steffen Prohaska, git
In-Reply-To: <0C176853-8848-46C8-AD7A-97F73274DC29@wincent.com>
Hi,
On Fri, 2 Nov 2007, Wincent Colaiuta wrote:
> Of course, it's too late too change now, but it would be nice if the
> mirror of "fetch" were "send". (I know it's been commented in the past
> that the fact that "push" and "pull" aren't mirror operations has
> surprised quite a few people.)
Could you please just do
git config --global alias.send push
and be done with it?
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2] War on whitespace: first, a bit of retreat.
From: Jakub Narebski @ 2007-11-02 12:25 UTC (permalink / raw)
To: git
In-Reply-To: <ee77f5c20711020450hdfe064fsace9349fe6494ec9@mail.gmail.com>
David Symonds wrote:
> On 11/2/07, Andreas Ericsson <ae@op5.se> wrote:
>> David Symonds wrote:
>>> On 11/2/07, Junio C Hamano <gitster@pobox.com> wrote:
>>>> This introduces core.whitespace configuration variable that lets
>>>> you specify the definition of "whitespace error".
>>>>
>>>> Currently there are two kinds of whitespace errors defined:
>>>>
>>>> * trailing-space: trailing whitespaces at the end of the line.
>>>>
>>>> * space-before-tab: a SP appears immediately before HT in the
>>>> indent part of the line.
>>>
>>>> [core]
>>>> whitespace = -trailing-space
>>>
>>> Could I suggest naming the option 'whitespaceError', so it's clearer
>>> that it's a negative setting?
>>
>> Which would also open the window for "WhitespaceWarning" and "WhitespaceAutofix"
>> later on, using the same semantics.
>
> Maybe cut straight to the chase:
>
> [core]
> whitespace.trailing = error
> whitespace.space-before-tab = error
> whitespace.8-spaces = warn
>
> There'd be at least "error", "warn"; "okay" and "autofix" would be
> other sensible values. I'm willing to help code this up if this sounds
> good.
Nice idea, but the syntax is
[core "whitespace"]
trailing = error
space-before-tab = error
indent-with-space = warn
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] status&commit: Teach them to show commits of modified submodules.
From: Ping Yin @ 2007-11-02 11:53 UTC (permalink / raw)
To: git; +Cc: Ping Yin
git status/commit just treats submodules as ordinary files when reporting status
changes. However, one may also wonder how the submodules change.
This commit teaches git status/commit to also show commits of
modified submodules since HEAD (or HEAD^ if --amend option is on).
For example, when commiting, submodule sm1 and sm2 are both changed. sm1 has commit C in HEAD and
commit E in index. The history of sm1 is
--A-->B-->C (in HEAD:354cd45)
\
-->D->E (in index:3f751e5)
git status will give the following output (just output commits of submodules
before normal output) to show how to change from commit C (in HEAD) to commit
E (in index): backward ('<<<') to commit A, and then forward ('>>>') to commit
E.
#
# submodule modifiled: sm1 sm2
#
# * sm1 354cd45...3f751e5:
# <<<
# one line message for C
# one line message for B
# >>>
# one line message for D
# one line message for E
#
# * sm2 5c8bfb5...ac46d84:
# <<<
# msg
#
# On branch master
# Changes to be committed:
# (use "git reset HEAD <file>..." to unstage)
#
# modified: sm1
# modified: sm2
---
git-commit.sh | 40 ++++++++++++++++++++++++++++++++++++++++
1 files changed, 40 insertions(+), 0 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index fcb8443..d362caa 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -33,6 +33,40 @@ save_index () {
cp -p "$THIS_INDEX" "$NEXT_INDEX"
}
+# Show log of modified submodule (index modification since HEAD or $1)
+show_module_log () {
+ modules=`git diff --cached --name-only $1 |
+ while read name
+ do
+ git ls-files --stage $name
+ done |
+ grep '^160000 ' | awk '{print $4}'`
+ test -z "$modules" && return
+
+ modules=$(echo $modules)
+ echo -e "#\n# submodule modifiled: $modules\n#"
+ for name in $modules
+ do
+ range=`git diff --cached -- $name | sed -n '2 p' | awk '{print $2}'`
+ indexone=${range#*..}
+ headone=${range%..*}
+ (
+ echo "* $name $headone...$indexone:"
+ cd $name >&/dev/null || { echo " Warning: fail to chdir to $name" && exit; }
+ left="`git log --pretty=oneline $indexone..$headone 2>&1 | sed 's/^\w\+ / \t/'`"
+ right="`git log --pretty=oneline --reverse $headone..$indexone 2>&1 | sed 's/^\w\+ / \t/'`"
+ if echo "$left$right" | grep 'unknown revision' >&/dev/null
+ then
+ echo " Warning: $name is not a repository or dosn't contains commit $headone/$indexone"
+ else
+ test -n "$left" && echo -e " <<<\n$left"
+ test -n "$right" && echo -e " >>>\n$right"
+ fi
+ echo
+ ) | sed 's/^/# /'
+ done
+}
+
run_status () {
# If TMP_INDEX is defined, that means we are doing
# "--only" partial commit, and that index file is used
@@ -55,6 +89,12 @@ run_status () {
else
color=--nocolor
fi
+ if test -z "$amend"
+ then
+ show_module_log
+ else
+ show_module_log "HEAD^"
+ fi
git runstatus ${color} \
${verbose:+--verbose} \
${amend:+--amend} \
--
1.5.3.4
^ permalink raw reply related
* Re: New features in gitk
From: Marco Costalba @ 2007-11-02 12:44 UTC (permalink / raw)
To: Paul Mackerras; +Cc: Linus Torvalds, git
In-Reply-To: <18218.63946.772767.179841@cargo.ozlabs.ibm.com>
On 11/2/07, Paul Mackerras <paulus@samba.org> wrote:
>
> In any case, no that's not the only reason. The main reason is that
> it (i.e. --topo-order) spits out the commits in exactly the order that
> gitk wants to display them (of which the bit about parents coming
> after all their children is a part), and thus reduces the amount of
> processing I need to do in Tcl.
>
I have tried to overcome --topo-order in qgit but I found it very
difficult, too much for me.
Lazily drawing the layout it doesn't mean that you lazy load the data
from git, indeed you load all the git-log output as soon as it
arrives.
And if the revisions arrive "in order", i.e. if revision A arrive
before revision B it means that A is NOT an ancestor of B, this is of
great help.
When drawing the graph assuming that the vector/list of the arrived
sha is already ordered greatly simplify the whole thing, if we relax
this hypothesis then a lot of work should be done before to draw a
graph chunk, essentially the GUI tool needs to walk the _entire_ list
and reorder it by itself _before_ to draw any graph chunk also if very
small.
So at the end you end up transferring the complete revision walk from
git-log to the GUI tool, and (this is the important thing) to be sure
graph is always correct you need to perform the walk _before_ drawing
any stuff.
The only possible _trick_ I was able to find is to optimistically draw
the graph chunk _assuming_ that it is ordered.
Then reorder the list in the background and finally check if the graph
is correct, if not redraw with correct data.
If the out of order revisions are rare you end up mimic a fast correct
drawing. If are not user will see some flickering at the end of the
load.
IMHO the above scheme is very complicated and fragile.
Just my two cents.
Marco
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Steffen Prohaska @ 2007-11-02 12:48 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Wincent Colaiuta, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0711021213370.4362@racer.site>
On Nov 2, 2007, at 1:14 PM, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 2 Nov 2007, Wincent Colaiuta wrote:
>
>> Of course, it's too late too change now, but it would be nice if the
>> mirror of "fetch" were "send". (I know it's been commented in the
>> past
>> that the fact that "push" and "pull" aren't mirror operations has
>> surprised quite a few people.)
>
> Could you please just do
>
> git config --global alias.send push
>
> and be done with it?
This would certainly be the easiest. But I think the following
is probably more in line with Wincent's comment:
Makefile builds git-send instead of git-push
git config --global alias.push send
[ wait some time ]
git config --unset alias.push
The comment was about how to avoid surprises for people that
are new to git, not how to let long-time users have an alias
for push.
The _only_ real solution I see right now, is to stop the
discussion and leave "git push" as is. I strongly believe that
the git community in its majority will refuse to rename push;
though I have no evidence for this.
Steffen
^ permalink raw reply
* Re: [PATCH 1/2] War on whitespace: first, a bit of retreat.
From: David Symonds @ 2007-11-02 12:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <fgf4qu$e8c$1@ger.gmane.org>
On 11/2/07, Jakub Narebski <jnareb@gmail.com> wrote:
> Nice idea, but the syntax is
>
> [core "whitespace"]
> trailing = error
> space-before-tab = error
> indent-with-space = warn
Whoops, of course. My brain is a bit muddled tonight.
Dave.
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Wincent Colaiuta @ 2007-11-02 13:11 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <A862668C-7895-489A-B13B-597084CAEE11@zib.de>
El 2/11/2007, a las 13:48, Steffen Prohaska escribió:
> On Nov 2, 2007, at 1:14 PM, Johannes Schindelin wrote:
>
>> On Fri, 2 Nov 2007, Wincent Colaiuta wrote:
>>
>>> Of course, it's too late too change now, but it would be nice if the
>>> mirror of "fetch" were "send". (I know it's been commented in the
>>> past
>>> that the fact that "push" and "pull" aren't mirror operations has
>>> surprised quite a few people.)
>>
>> Could you please just do
>>
>> git config --global alias.send push
>>
>> and be done with it?
(snip)
> The comment was about how to avoid surprises for people that
> are new to git, not how to let long-time users have an alias
> for push.
Exactly. I was talking about the *initial* surprise for new users, not
for people who already know the difference between push, pull and
fetch (99% of people reading this list already, myself included).
> The _only_ real solution I see right now, is to stop the
> discussion and leave "git push" as is. I strongly believe that
> the git community in its majority will refuse to rename push;
> though I have no evidence for this.
As I said above, "Of course, it's too late to change now"... I don't
think it will be renamed either.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Tom Prince @ 2007-11-02 13:24 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Steffen Prohaska, Junio C Hamano, git
In-Reply-To: <472AF5F8.40208@op5.se>
On Fri, Nov 02, 2007 at 11:03:36AM +0100, Andreas Ericsson wrote:
> Steffen Prohaska wrote:
>> On Nov 1, 2007, at 10:11 AM, Andreas Ericsson wrote:
>>>
>>> It's easier to bisect. If git bisect lands you on a merge-commit,
>>> you need to start a new bisect for each of the parents included
>>> in the merge. Hopefully the nature of the merge gives a clue so
>>> the user can make an educated guess as to which parent introduced
>>> the bogus commit, but for an "evil octopus" (unusual) or if the
>>> merge had conflicts which were resolved in a buggy way (not
>>> exactly uncommon), it can be quite a hassle to get things right.
>>> With a mostly linear history, this problem goes away.
>> This is really an interesting point. I did not start to use
>> git bisect regularly. But I certainly plan to do so in the future.
>> Couldn't bisect learn to better cope with non-linear history?
>
> Perhaps it could, but it's far from trivial. I started hacking on
> a wrapper for git-bisect which would do just that, but gave up
> rather quickly as the book-keeping required to remember each and
> every parent-point tried just got out of hand, and it *still*
> wouldn't run in full automatic. It broke down because I also
> wanted merges on non-first-line parents to be delved into. If
> that didn't happen, I wouldn't *know* the bisect would run fine
> without me watching it, so then it was as useless as if I'd have
> had to sit there the entire time anyway.
I haven't had occasion to use git-bisect much, but I was under the
impression that bisect could already handle merges, or any other shaped
history just fine.
If you test a merge and it is bad, git (eventually) picks a commit on one of
the branches. If that commit is good, then the merge-base is good, so that the
bug lies on some other branch. If that commit is bad, then the bug is on some
ancestor of the branch. Thus, no need for special book keeping.
Tom
^ permalink raw reply
* Re: [PATCH 1/2] War on whitespace: first, a bit of retreat.
From: David Symonds @ 2007-11-02 13:26 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <ee77f5c20711020553x1a329fa5g90f38d5b8c1a062e@mail.gmail.com>
On 11/2/07, David Symonds <dsymonds@gmail.com> wrote:
> On 11/2/07, Jakub Narebski <jnareb@gmail.com> wrote:
> > Nice idea, but the syntax is
> >
> > [core "whitespace"]
> > trailing = error
> > space-before-tab = error
> > indent-with-space = warn
>
> Whoops, of course. My brain is a bit muddled tonight.
Okay, I've put my money where my mouth is, and coded up an equivalent
to Junio's patch from the start of this thread. I'll send it through
in a couple of minutes.
Dave.
^ permalink raw reply
* [PATCH 1/3] Implement parsing for new core.whitespace.* options.
From: David Symonds @ 2007-11-02 13:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Andreas Ericsson, David Symonds
Each of the new core.whitespace.* options (enumerated below) can be set to one
of:
* okay (default): Whitespace of this type is okay
* warn: Whitespace of this type should be warned about
* error: Whitespace of this type should raise an error
* autofix: Whitespace of this type should be automatically fixed
The initial options are:
* trailing: Whitespace at the end of a line
* space-before-tab: SP HT sequence in the initial whitespace of a line
* space-indent: At least 8 spaces in a row at the start of a line
Example usage:
[core "whitespace"]
trailing = autofix
space-before-tab = error
space-indent = warn
Signed-off-by: David Symonds <dsymonds@gmail.com>
---
cache.h | 16 ++++++++++++++++
config.c | 28 ++++++++++++++++++++++++++++
environment.c | 3 +++
3 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/cache.h b/cache.h
index bfffa05..51e3982 100644
--- a/cache.h
+++ b/cache.h
@@ -602,4 +602,20 @@ extern int diff_auto_refresh_index;
/* match-trees.c */
void shift_tree(const unsigned char *, const unsigned char *, unsigned char *, int);
+/*
+ * whitespace rules.
+ * used by both diff and apply
+ */
+enum whitespace_mode {
+ WS_OKAY = 0,
+ WS_WARN,
+ WS_ERROR,
+ WS_AUTOFIX
+};
+extern enum whitespace_mode ws_mode_trailing;
+extern enum whitespace_mode ws_mode_space_before_tab;
+extern enum whitespace_mode ws_mode_space_indent;
+extern enum whitespace_mode git_config_whitespace_mode(const char *, const char *);
+
+
#endif /* CACHE_H */
diff --git a/config.c b/config.c
index dc3148d..8e6f252 100644
--- a/config.c
+++ b/config.c
@@ -297,6 +297,19 @@ int git_config_bool(const char *name, const char *value)
return git_config_int(name, value) != 0;
}
+enum whitespace_mode git_config_whitespace_mode(const char *name, const char *value)
+{
+ if (!strcasecmp(value, "okay"))
+ return WS_OKAY;
+ if (!strcasecmp(value, "warn"))
+ return WS_WARN;
+ if (!strcasecmp(value, "error"))
+ return WS_ERROR;
+ if (!strcasecmp(value, "autofix"))
+ return WS_AUTOFIX;
+ die("bad config value for '%s' in %s", name, config_file_name);
+}
+
int git_default_config(const char *var, const char *value)
{
/* This needs a better name */
@@ -431,6 +444,21 @@ int git_default_config(const char *var, const char *value)
return 0;
}
+ if (!strcmp(var, "core.whitespace.trailing")) {
+ ws_mode_trailing = git_config_whitespace_mode(var, value);
+ return 0;
+ }
+
+ if (!strcmp(var, "core.whitespace.space-before-tab")) {
+ ws_mode_space_before_tab = git_config_whitespace_mode(var, value);
+ return 0;
+ }
+
+ if (!strcmp(var, "core.whitespace.space-indent")) {
+ ws_mode_space_indent = git_config_whitespace_mode(var, value);
+ return 0;
+ }
+
/* Add other config variables here and to Documentation/config.txt. */
return 0;
}
diff --git a/environment.c b/environment.c
index b5a6c69..71502fc 100644
--- a/environment.c
+++ b/environment.c
@@ -35,6 +35,9 @@ int pager_in_use;
int pager_use_color = 1;
char *editor_program;
int auto_crlf = 0; /* 1: both ways, -1: only when adding git objects */
+enum whitespace_mode ws_mode_trailing = WS_OKAY;
+enum whitespace_mode ws_mode_space_before_tab = WS_OKAY;
+enum whitespace_mode ws_mode_space_indent = WS_OKAY;
/* This is set by setup_git_dir_gently() and/or git_default_config() */
char *git_work_tree_cfg;
--
1.5.3.1
^ permalink raw reply related
* [PATCH 2/3] Act on WS_WARN for ws_mode_space_before_tab.
From: David Symonds @ 2007-11-02 13:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Andreas Ericsson, David Symonds
In-Reply-To: <11940104611948-git-send-email-dsymonds@gmail.com>
Signed-off-by: David Symonds <dsymonds@gmail.com>
---
diff.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/diff.c b/diff.c
index a6aaaf7..6f9b624 100644
--- a/diff.c
+++ b/diff.c
@@ -508,8 +508,12 @@ static void emit_line_with_ws(int nparents,
for (i = col0; i < len; i++) {
if (line[i] == '\t') {
last_tab_in_indent = i;
- if (0 <= last_space_in_indent)
- need_highlight_leading_space = 1;
+ if ((ws_mode_space_before_tab != WS_OKAY) &&
+ (0 <= last_space_in_indent)) {
+ if (ws_mode_space_before_tab == WS_WARN)
+ need_highlight_leading_space = 1;
+ /* TODO: handle WS_ERROR and WS_AUTOFIX */
+ }
}
else if (line[i] == ' ')
last_space_in_indent = i;
--
1.5.3.1
^ permalink raw reply related
* [PATCH 3/3] Act on WS_WARN for ws_mode_trailing.
From: David Symonds @ 2007-11-02 13:34 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Andreas Ericsson, David Symonds
In-Reply-To: <11940104621856-git-send-email-dsymonds@gmail.com>
Signed-off-by: David Symonds <dsymonds@gmail.com>
---
diff.c | 21 +++++++++++++--------
1 files changed, 13 insertions(+), 8 deletions(-)
diff --git a/diff.c b/diff.c
index 6f9b624..ebcc0f3 100644
--- a/diff.c
+++ b/diff.c
@@ -544,17 +544,22 @@ static void emit_line_with_ws(int nparents,
tail = len - 1;
if (line[tail] == '\n' && i < tail)
tail--;
- while (i < tail) {
- if (!isspace(line[tail]))
- break;
- tail--;
+ if (ws_mode_trailing != WS_OKAY) {
+ while (i < tail) {
+ if (!isspace(line[tail]))
+ break;
+ tail--;
+ }
}
if ((i < tail && line[tail + 1] != '\n')) {
/* This has whitespace between tail+1..len */
- fputs(set, stdout);
- fwrite(line + i, tail - i + 1, 1, stdout);
- fputs(reset, stdout);
- emit_line(ws, reset, line + tail + 1, len - tail - 1);
+ if (ws_mode_trailing == WS_WARN) {
+ fputs(set, stdout);
+ fwrite(line + i, tail - i + 1, 1, stdout);
+ fputs(reset, stdout);
+ emit_line(ws, reset, line + tail + 1, len - tail - 1);
+ }
+ /* TODO: handle WS_ERROR and WS_AUTOFIX */
}
else
emit_line(set, reset, line + i, len - i);
--
1.5.3.1
^ permalink raw reply related
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Andreas Ericsson @ 2007-11-02 13:52 UTC (permalink / raw)
To: Tom Prince; +Cc: Steffen Prohaska, Junio C Hamano, git
In-Reply-To: <20071102132446.GA31758@hermes.priv>
Tom Prince wrote:
> On Fri, Nov 02, 2007 at 11:03:36AM +0100, Andreas Ericsson wrote:
>> Steffen Prohaska wrote:
>>> On Nov 1, 2007, at 10:11 AM, Andreas Ericsson wrote:
>>>> It's easier to bisect. If git bisect lands you on a merge-commit,
>>>> you need to start a new bisect for each of the parents included
>>>> in the merge. Hopefully the nature of the merge gives a clue so
>>>> the user can make an educated guess as to which parent introduced
>>>> the bogus commit, but for an "evil octopus" (unusual) or if the
>>>> merge had conflicts which were resolved in a buggy way (not
>>>> exactly uncommon), it can be quite a hassle to get things right.
>>>> With a mostly linear history, this problem goes away.
>>> This is really an interesting point. I did not start to use
>>> git bisect regularly. But I certainly plan to do so in the future.
>>> Couldn't bisect learn to better cope with non-linear history?
>> Perhaps it could, but it's far from trivial. I started hacking on
>> a wrapper for git-bisect which would do just that, but gave up
>> rather quickly as the book-keeping required to remember each and
>> every parent-point tried just got out of hand, and it *still*
>> wouldn't run in full automatic. It broke down because I also
>> wanted merges on non-first-line parents to be delved into. If
>> that didn't happen, I wouldn't *know* the bisect would run fine
>> without me watching it, so then it was as useless as if I'd have
>> had to sit there the entire time anyway.
>
> I haven't had occasion to use git-bisect much, but I was under the
> impression that bisect could already handle merges, or any other shaped
> history just fine.
>
It appears the code supports your statement. I started writing on my
hack-around about a year ago, and the merge-handling code got in with
1c4fea3a40e836dcee2f16091bf7bfba96c924d0 at Wed Mar 21 22:16:24 2007.
Perhaps I shouldn't be so paranoid about useless merges anymore then.
Hmm. I shall have to look into it. Perhaps Junio can clarify how it
works? The man-page was terribly silent about how git-bisect handles
merges.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Make git-clone obey "--" (end argument parsing)
From: Heikki Orsila @ 2007-11-02 14:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Junio C Hamano wrote:
> I do not think this breaks anything, but does it _help_
> anything in practice?
>
> What kind of breakage does this patch fix?
It doesn't fix anything, but it is a good usability standard to obey --.
I was creating a script that would _automatically_ clone repositories of
other users. As a little bit pedantic shell script writer I added "--"
and noticed that git clone doesn't handle that, although it's expected
behavior from many tools.
--
Heikki Orsila Barbie's law:
heikki.orsila@iki.fi "Math is hard, let's go shopping!"
http://www.iki.fi/shd
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Steffen Prohaska @ 2007-11-02 14:49 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Tom Prince, Junio C Hamano, git
In-Reply-To: <472B2B8F.1060203@op5.se>
On Nov 2, 2007, at 2:52 PM, Andreas Ericsson wrote:
>> I haven't had occasion to use git-bisect much, but I was under the
>> impression that bisect could already handle merges, or any other
>> shaped
>> history just fine.
>
> It appears the code supports your statement. I started writing on my
> hack-around about a year ago, and the merge-handling code got in with
> 1c4fea3a40e836dcee2f16091bf7bfba96c924d0 at Wed Mar 21 22:16:24 2007.
> Perhaps I shouldn't be so paranoid about useless merges anymore then.
> Hmm. I shall have to look into it. Perhaps Junio can clarify how it
> works? The man-page was terribly silent about how git-bisect handles
> merges.
So eventually there's coming something good out of this thread,
without actually writing any code ;)
Steffen
^ permalink raw reply
* Re: New features in gitk
From: Linus Torvalds @ 2007-11-02 15:03 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <18218.63946.772767.179841@cargo.ozlabs.ibm.com>
On Fri, 2 Nov 2007, Paul Mackerras wrote:
>
> How would that help? That doesn't list about 2/3 of the commits at
> all.
Yeah, you'd have to do all the parent processing on your own, I guess that
would be too slow.
> In any case, no that's not the only reason. The main reason is that
> it (i.e. --topo-order) spits out the commits in exactly the order that
> gitk wants to display them (of which the bit about parents coming
> after all their children is a part), and thus reduces the amount of
> processing I need to do in Tcl.
The thing is, you shouldn't *care* how long it takes to get 50,000+
commits.
You're only visualizing ~20 commits at a time. Ignore the rest.
THAT is the number that is timing-critical. You're optimizing for the
wrong case - the "whole history" thing doesn't matter as much as the
"recent history" does.
So I bet from a usability standpoint, you'd be *much* better off with
something that might take ten times as long for the whole thing, if the
first thirty lines show up in a third of the time.
In fact, if you want to really optimize parsing and that is a big issue,
use
git log --left-right --parents --pretty=format:"%m %H %P %an <%ae> %aD"
which will give you a single line per commit. I bet tk is good at reading
single lines. Don't even read anythign else - until somebody actually
*selects* the commit, at which point you do the diff *and* the full thing.
Yes, it will make things slower over-all. And no, the above won't work for
the "search everywhere", which means that once people start searching for
everything, you'll be screwed, but with somethign like the above, you'll
get the first commits immediately and can start showing them.
And yes, if they come in the wrong order, you'll have to recalculate the
display, but I thought you had something incremental already - ie you can
always do it for just the current window of 100 commits or whatever.
Linus
^ permalink raw reply
* Re: [PATCH 3/3] Act on WS_WARN for ws_mode_trailing.
From: David Symonds @ 2007-11-02 15:07 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Andreas Ericsson, David Symonds
In-Reply-To: <1194010463982-git-send-email-dsymonds@gmail.com>
On 11/3/07, David Symonds <dsymonds@gmail.com> wrote:
> Signed-off-by: David Symonds <dsymonds@gmail.com>
> ---
> diff.c | 21 +++++++++++++--------
> 1 files changed, 13 insertions(+), 8 deletions(-)
Silly me; I somehow forgot I was only in diff.c. I'll fix and repost the series.
Dave.
^ permalink raw reply
* [PATCH 1/2] Implement parsing for new core.whitespace.* options.
From: David Symonds @ 2007-11-02 15:08 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Andreas Ericsson, David Symonds
Each of the new core.whitespace.* options (enumerated below) can be set to one
of:
* okay (default): Whitespace of this type is okay
* warn: Whitespace of this type should be warned about
* error: Whitespace of this type should raise an error
* autofix: Whitespace of this type should be automatically fixed
The initial options are:
* trailing: Whitespace at the end of a line
* space-before-tab: SP HT sequence in the initial whitespace of a line
* space-indent: At least 8 spaces in a row at the start of a line
Example usage:
[core "whitespace"]
trailing = autofix
space-before-tab = error
space-indent = warn
Signed-off-by: David Symonds <dsymonds@gmail.com>
---
cache.h | 16 ++++++++++++++++
config.c | 28 ++++++++++++++++++++++++++++
environment.c | 3 +++
3 files changed, 47 insertions(+), 0 deletions(-)
diff --git a/cache.h b/cache.h
index bfffa05..51e3982 100644
--- a/cache.h
+++ b/cache.h
@@ -602,4 +602,20 @@ extern int diff_auto_refresh_index;
/* match-trees.c */
void shift_tree(const unsigned char *, const unsigned char *, unsigned char *, int);
+/*
+ * whitespace rules.
+ * used by both diff and apply
+ */
+enum whitespace_mode {
+ WS_OKAY = 0,
+ WS_WARN,
+ WS_ERROR,
+ WS_AUTOFIX
+};
+extern enum whitespace_mode ws_mode_trailing;
+extern enum whitespace_mode ws_mode_space_before_tab;
+extern enum whitespace_mode ws_mode_space_indent;
+extern enum whitespace_mode git_config_whitespace_mode(const char *, const char *);
+
+
#endif /* CACHE_H */
diff --git a/config.c b/config.c
index dc3148d..8e6f252 100644
--- a/config.c
+++ b/config.c
@@ -297,6 +297,19 @@ int git_config_bool(const char *name, const char *value)
return git_config_int(name, value) != 0;
}
+enum whitespace_mode git_config_whitespace_mode(const char *name, const char *value)
+{
+ if (!strcasecmp(value, "okay"))
+ return WS_OKAY;
+ if (!strcasecmp(value, "warn"))
+ return WS_WARN;
+ if (!strcasecmp(value, "error"))
+ return WS_ERROR;
+ if (!strcasecmp(value, "autofix"))
+ return WS_AUTOFIX;
+ die("bad config value for '%s' in %s", name, config_file_name);
+}
+
int git_default_config(const char *var, const char *value)
{
/* This needs a better name */
@@ -431,6 +444,21 @@ int git_default_config(const char *var, const char *value)
return 0;
}
+ if (!strcmp(var, "core.whitespace.trailing")) {
+ ws_mode_trailing = git_config_whitespace_mode(var, value);
+ return 0;
+ }
+
+ if (!strcmp(var, "core.whitespace.space-before-tab")) {
+ ws_mode_space_before_tab = git_config_whitespace_mode(var, value);
+ return 0;
+ }
+
+ if (!strcmp(var, "core.whitespace.space-indent")) {
+ ws_mode_space_indent = git_config_whitespace_mode(var, value);
+ return 0;
+ }
+
/* Add other config variables here and to Documentation/config.txt. */
return 0;
}
diff --git a/environment.c b/environment.c
index b5a6c69..71502fc 100644
--- a/environment.c
+++ b/environment.c
@@ -35,6 +35,9 @@ int pager_in_use;
int pager_use_color = 1;
char *editor_program;
int auto_crlf = 0; /* 1: both ways, -1: only when adding git objects */
+enum whitespace_mode ws_mode_trailing = WS_OKAY;
+enum whitespace_mode ws_mode_space_before_tab = WS_OKAY;
+enum whitespace_mode ws_mode_space_indent = WS_OKAY;
/* This is set by setup_git_dir_gently() and/or git_default_config() */
char *git_work_tree_cfg;
--
1.5.3.1
^ permalink raw reply related
* [PATCH 2/2] git-diff: Respect core.whitespace.{space-indent,space-before-tab,trailing}.
From: David Symonds @ 2007-11-02 15:08 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Andreas Ericsson, David Symonds
In-Reply-To: <11940160932021-git-send-email-dsymonds@gmail.com>
Signed-off-by: David Symonds <dsymonds@gmail.com>
---
diff.c | 24 ++++++++++++++++++------
1 files changed, 18 insertions(+), 6 deletions(-)
diff --git a/diff.c b/diff.c
index a6aaaf7..aa86fa1 100644
--- a/diff.c
+++ b/diff.c
@@ -503,12 +503,15 @@ static void emit_line_with_ws(int nparents,
int tail = len;
int need_highlight_leading_space = 0;
/* The line is a newly added line. Does it have funny leading
- * whitespaces? In indent, SP should never precede a TAB.
+ * whitespaces? In indent, SP should never precede a TAB. In
+ * addition, under "indent with non tab" rule, there should not
+ * be 8 or more consecutive spaces.
*/
for (i = col0; i < len; i++) {
if (line[i] == '\t') {
last_tab_in_indent = i;
- if (0 <= last_space_in_indent)
+ if ((ws_mode_space_before_tab != WS_OKAY) &&
+ (0 <= last_space_in_indent))
need_highlight_leading_space = 1;
}
else if (line[i] == ' ')
@@ -516,6 +519,13 @@ static void emit_line_with_ws(int nparents,
else
break;
}
+ if ((ws_mode_space_indent != WS_OKAY) &&
+ (0 <= last_space_in_indent) &&
+ (last_tab_in_indent < 0) &&
+ (8 <= (i - col0))) {
+ last_tab_in_indent = i;
+ need_highlight_leading_space = 1;
+ }
fputs(set, stdout);
fwrite(line, col0, 1, stdout);
fputs(reset, stdout);
@@ -540,10 +550,12 @@ static void emit_line_with_ws(int nparents,
tail = len - 1;
if (line[tail] == '\n' && i < tail)
tail--;
- while (i < tail) {
- if (!isspace(line[tail]))
- break;
- tail--;
+ if (ws_mode_trailing != WS_OKAY) {
+ while (i < tail) {
+ if (!isspace(line[tail]))
+ break;
+ tail--;
+ }
}
if ((i < tail && line[tail + 1] != '\n')) {
/* This has whitespace between tail+1..len */
--
1.5.3.1
^ permalink raw reply related
* [PATCH] Update git-sh-setup(1) to allow transparent use of git-parseopt(1)
From: Pierre Habouzit @ 2007-11-02 15:09 UTC (permalink / raw)
To: gitster, torvalds, Junio C Hamano, Linus Torvalds; +Cc: git, Pierre Habouzit
In-Reply-To: <1194016162-23599-2-git-send-email-madcoder@debian.org>
If you set OPTIONS_SPEC, git-sh-setups uses git-parseopt automatically.
It also diverts usage to re-exec $0 with the -h option as parse-options.c
will catch that.
PARSEOPT_OPTS can also be used to pass options git git-parseopt(1) (like
--keep-dashdash).
---
git-sh-setup.sh | 44 ++++++++++++++++++++++++++------------------
1 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index 86d7d4c..d7b13e0 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -16,9 +16,32 @@ die() {
exit 1
}
-usage() {
- die "Usage: $0 $USAGE"
-}
+if test -n "$OPTIONS_SPEC"; then
+ usage() {
+ exec "$0" -h
+ }
+
+ eval `echo "$OPTIONS_SPEC" | git parseopt $PARSEOPT_OPTS -- "$@" || echo exit $?`
+else
+ usage() {
+ die "Usage: $0 $USAGE"
+ }
+
+ if [ -z "$LONG_USAGE" ]
+ then
+ LONG_USAGE="Usage: $0 $USAGE"
+ else
+ LONG_USAGE="Usage: $0 $USAGE
+
+$LONG_USAGE"
+ fi
+
+ case "$1" in
+ -h|--h|--he|--hel|--help)
+ echo "$LONG_USAGE"
+ exit
+ esac
+fi
set_reflog_action() {
if [ -z "${GIT_REFLOG_ACTION:+set}" ]
@@ -91,21 +114,6 @@ get_author_ident_from_commit () {
LANG=C LC_ALL=C sed -ne "$pick_author_script"
}
-if [ -z "$LONG_USAGE" ]
-then
- LONG_USAGE="Usage: $0 $USAGE"
-else
- LONG_USAGE="Usage: $0 $USAGE
-
-$LONG_USAGE"
-fi
-
-case "$1" in
- -h|--h|--he|--hel|--help)
- echo "$LONG_USAGE"
- exit
-esac
-
# Make sure we are in a valid repository of a vintage we understand.
if [ -z "$SUBDIRECTORY_OK" ]
then
--
1.5.3.5.1458.g2aa13-dirty
^ permalink raw reply related
* [PATCH] Migrate git-clean.sh to use git-parseoptions(1)
From: Pierre Habouzit @ 2007-11-02 15:09 UTC (permalink / raw)
To: gitster, torvalds, Junio C Hamano, Linus Torvalds; +Cc: git, Pierre Habouzit
In-Reply-To: <1194016162-23599-3-git-send-email-madcoder@debian.org>
Also minor consistency tweaks in how errors are caught.
---
This patch is a pretty good example of the fact that git-parseopt(1)
is not very disruptive to the general coding style thanks to
git-sh-setup.
git-clean.sh | 38 ++++++++++++++++++++------------------
1 files changed, 20 insertions(+), 18 deletions(-)
diff --git a/git-clean.sh b/git-clean.sh
index 4491738..6959433 100755
--- a/git-clean.sh
+++ b/git-clean.sh
@@ -3,16 +3,21 @@
# Copyright (c) 2005-2006 Pavel Roskin
#
-USAGE="[-d] [-f] [-n] [-q] [-x | -X] [--] <paths>..."
-LONG_USAGE='Clean untracked files from the working directory
- -d remove directories as well
- -f override clean.requireForce and clean anyway
- -n don'\''t remove anything, just show what would be done
- -q be quiet, only report errors
- -x remove ignored files as well
- -X remove only ignored files
+OPTIONS_SPEC="\
+git-clean [options] <paths>...
+
+Clean untracked files from the working directory
+
When optional <paths>... arguments are given, the paths
-affected are further limited to those that match them.'
+affected are further limited to those that match them.
+--
+d remove directories as well
+f override clean.requireForce and clean anyway
+n don't remove anything, just show what would be done
+q be quiet, only report errors
+x remove ignored files as well
+X remove only ignored files"
+
SUBDIRECTORY_OK=Yes
. git-sh-setup
require_work_tree
@@ -55,23 +60,20 @@ do
shift
break
;;
- -*)
- usage
- ;;
*)
- break
+ usage # should not happen
+ ;;
esac
shift
done
if [ "$disabled" = true ]; then
- echo "clean.requireForce set and -n or -f not given; refusing to clean"
- exit 1
+ die "clean.requireForce set and -n or -f not given; refusing to clean"
fi
-case "$ignored,$ignoredonly" in
- 1,1) usage;;
-esac
+if [ "$ignored,$ignoredonly" = "1,1" ]; then
+ die "-x and -X cannot be set together"
+fi
if [ -z "$ignored" ]; then
excl="--exclude-per-directory=.gitignore"
--
1.5.3.5.1458.g2aa13-dirty
^ 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