* 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
* [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
* [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 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
* 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
* 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 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 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: 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: 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
* [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: [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
* 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: 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: 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: 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] 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: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2007-11-02 11:03 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Linus Torvalds, Junio C Hamano, git
In-Reply-To: <472AF01F.9030002@op5.se>
Hi,
On Fri, 2 Nov 2007, Andreas Ericsson wrote:
> Linus Torvalds wrote:
> >
> > On Wed, 31 Oct 2007, Junio C Hamano wrote:
> > > * ph/parseopt (Tue Oct 30 14:15:21 2007 -0500) 23 commits
> > > + ...
> > >
> > > It appears 1.5.4 will be, to a certain extent, a "Let's clean up
> > > the internal implementation" release. This series should become
> > > part of it. Hopefully will merge to 'master' soon, but I
> > > haven't looked this series very closely yet.
> >
> > I certainly think this should go in, but it does make one deficiency
> > painfully clear: the remaining shell scripts end up having all the old
> > flags behaviour.
> >
> > So while you can combine flags for *most* programs, you still won't be able
> > to say things like
> >
> > git clean -qdx
> >
> > just because that's still a shellscript, and doing any fancy argument
> > parsing in shell is just painful.
> >
> > Is somebody still working on doing the shell->C conversion?
> >
>
> Me, although my git work is happening with the speed of continental drift
> at the moment.
>
> git-merge and git-pull are (slowly) being converted. It's more in the
> nature of a learning experience for me than "oh shit I need this fast"
> though. Hence the blazing speed with which I work ;-)
If you would share what you have on repo.or.cz, others could help at a
faster pace, instead of duplicating your work or waiting for you to
finish.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 1/2] War on whitespace: first, a bit of retreat.
From: Andreas Ericsson @ 2007-11-02 10:45 UTC (permalink / raw)
To: David Symonds; +Cc: Junio C Hamano, git, Brian Downing
In-Reply-To: <ee77f5c20711020314h43290dbs8141cb3905c867@mail.gmail.com>
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. Personally, I'd like to get warnings for
non-tab-indent^H^H^H indent-with-non-tab (rename that option, perhaps?), autofix
for trailing-whitespace and errors for space-before-tab, with command-line
switch to override config settings.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 10/10] push: teach push to be quiet if local ref is strict subset of remote ref
From: Junio C Hamano @ 2007-11-02 10:44 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Andreas Ericsson, git
In-Reply-To: <417C801B-5DFF-4753-AB32-0FA1EB30C8E2@zib.de>
Steffen Prohaska <prohaska@zib.de> writes:
> - in a pull-oriented workflow (Linux kernel, git) ...
> ... There's maybe also less need to push to heads named
> differently on the local and the remote (though I'm not sure
> if this really true).
That's far from true but is irrelevant to the discussion of
supporting shared repositories better.
> - 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?
$ git clone $public my-work-dir
$ cd my-work-dir
$ git checkout -b --track foo origin/foo
$ 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.
With your "remote.$public.push = HEAD", the last step would be
"git push" without any parameter.
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
$ 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 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:
$ git fetch
$ git rebase origin/foo topic1
$ git branch -f foo origin/foo
$ git checkout foo
$ git merge topic1
$ git merge topic2
$ test test test
$ git push
> ... 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.
^ permalink raw reply
* Re: New features in gitk
From: Paul Mackerras @ 2007-11-02 10:19 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <alpine.LFD.0.999.0711010815320.3342@woody.linux-foundation.org>
Linus Torvalds writes:
> If that's the only reason for using it, then please stop, and use
> "--first-parent" instead.
How would that help? That doesn't list about 2/3 of the commits at
all.
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.
Paul.
^ permalink raw reply
* Re: [PATCH] post-update hook: update working copy
From: Andreas Ericsson @ 2007-11-02 10:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sam Vilain, git
In-Reply-To: <7vd4ut7948.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Sam Vilain <sam.vilain@catalyst.net.nz> writes:
>
>> Now that git-stash is available, it is not so unsafe to push to a
>> non-bare repository, but care needs to be taken to preserve any dirty
>> working copy or index state. This hook script does that, using
>> git-stash.
>
> Honestly, I am reluctant to do things that _encourages_ pushing
> into a live tree.
>
"Live" and "living" are perhaps two different things here. I for one have
something similar, but only for repositories residing on certain servers,
where there really must be zero local changes to the working tree.
> - Who guarantees that the reflog is enabled for the HEAD?
>
I disable reflogs on that server. There's (hardly ever) any human interaction
with the scripts in that repo, so I really, really don't care about reflogs.
> - Who guarantees that a human user is not actively editing the
> work tree files without saving?
There are times when one simply doesn't care.
I realize that for my situation, a much simpler script can (and is) used, so
I agree with your concerns. The idea that every git repo has a human hacking
on it isn't true though, so doing things like this are sometimes useful,
timesaving and a real help.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Mac OS X 10.5 does not require the OLD_ICONV flag set
From: Junio C Hamano @ 2007-11-02 10:33 UTC (permalink / raw)
To: David Symonds; +Cc: Junio C Hamano, Blake Ramsdell, git
In-Reply-To: <ee77f5c20711020319l26b4a8c1r99576dc29ea504d8@mail.gmail.com>
"David Symonds" <dsymonds@gmail.com> writes:
> On 11/2/07, Junio C Hamano <gitster@pobox.com> wrote:
>> Blake Ramsdell <blaker@gmail.com> writes:
>>
>> > Signed-off-by: Blake Ramsdell <blaker@gmail.com>
>> > ---
>> > Makefile | 4 +++-
>> > 1 files changed, 3 insertions(+), 1 deletions(-)
>> >
>> > diff --git a/Makefile b/Makefile
>> > index 71479a2..5d83756 100644
>> > --- a/Makefile
>> > +++ b/Makefile
>> > @@ -401,7 +401,9 @@ endif
>> > ifeq ($(uname_S),Darwin)
>> > NEEDS_SSL_WITH_CRYPTO = YesPlease
>> > NEEDS_LIBICONV = YesPlease
>> > - OLD_ICONV = UnfortunatelyYes
>> > + ifneq ($(uname_R),9.0.0)
>> > + OLD_ICONV = UnfortunatelyYes
>> > + endif
>> > NO_STRLCPY = YesPlease
>> > NO_MEMMEM = YesPlease
>> > endif
>>
>> I do not have an access to a Darwin box, but do you mean 10.5
>> gives 9.0.0 as uname_R?
>
> 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?
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Wincent Colaiuta @ 2007-11-02 10:26 UTC (permalink / raw)
To: Brian Downing; +Cc: Junio C Hamano, git
In-Reply-To: <20071101214131.GF4099@lavos.net>
El 1/11/2007, a las 22:41, Brian Downing escribió:
> On Wed, Oct 31, 2007 at 10:41:06PM -0700, Junio C Hamano wrote:
>> * jc/spht (Tue Oct 2 18:00:27 2007 -0700) 1 commit
>> - git-diff: complain about >=8 consecutive spaces in initial indent
>>
>> This is a counterpart of an earlier patch from J. Bruce Fields
>> to change "git-apply --whitespace" to make SP{8,} at the
>> beginning of line a whitespace error.
>>
>> Personally, I am in favor of the stricter check, but I had to
>> reject the "git-apply" patch because there was no way to disable
>> the additional check without disabling the existing check for
>> trailing whitespaces. We probably would want to revisit that
>> one (perhaps with a new option and/or config to selectively
>> enable different kinds of whitespace check).
>
> Just to throw in my two cents, I would be strongly opposed to this
> going in without some form of configuration to make it work for
> spaces-only-indent projects.
Ditto, I also work on some projects which have a spaces-only policy,
and the proposed change would be quite painful when working on those
projects, so configurability would be very important to me.
Cheers,
Wincent
^ permalink raw reply
* Re: [PATCH] Mac OS X 10.5 does not require the OLD_ICONV flag set
From: David Symonds @ 2007-11-02 10:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Blake Ramsdell, git
In-Reply-To: <7v4pg55893.fsf@gitster.siamese.dyndns.org>
On 11/2/07, Junio C Hamano <gitster@pobox.com> wrote:
> Blake Ramsdell <blaker@gmail.com> writes:
>
> > Signed-off-by: Blake Ramsdell <blaker@gmail.com>
> > ---
> > Makefile | 4 +++-
> > 1 files changed, 3 insertions(+), 1 deletions(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 71479a2..5d83756 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -401,7 +401,9 @@ endif
> > ifeq ($(uname_S),Darwin)
> > NEEDS_SSL_WITH_CRYPTO = YesPlease
> > NEEDS_LIBICONV = YesPlease
> > - OLD_ICONV = UnfortunatelyYes
> > + ifneq ($(uname_R),9.0.0)
> > + OLD_ICONV = UnfortunatelyYes
> > + endif
> > NO_STRLCPY = YesPlease
> > NO_MEMMEM = YesPlease
> > endif
>
> I do not have an access to a Darwin box, but do you mean 10.5
> gives 9.0.0 as uname_R?
Further, that comparison is going to fail as soon as the next revision
of Darwin (9.0.1, etc.) is released.
Dave.
^ 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