* Re: the war on trailing whitespace
From: Josef Weidendorfer @ 2006-02-27 16:08 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4403086F.5040704@op5.se>
On Monday 27 February 2006 15:10, you wrote:
> So in essence, a multi-line statement is closed when a completely empty
> line is found,
As I read this reference, such handling of completely empty lines is
done only in interactive mode, ie. when python is attached to a terminal...
Git is about storing python scripts, and not "interactive input"; therefore,
this seems to be a non-issue.
I just checked it. The following, with a completely empty line 3, is working
as expected, and not looping on an empty statement:
===================
a = ['cat', 'window', 'defenestrate']
for x in a:
print x, len(x)
===================
Josef
PS: I am not a python programmer...
^ permalink raw reply
* Re: Quick question: how to generate a patch?
From: Linus Torvalds @ 2006-02-27 16:04 UTC (permalink / raw)
To: Aubrey; +Cc: git
In-Reply-To: <6d6a94c50602270657m453cc581p6ec290c20879de25@mail.gmail.com>
On Mon, 27 Feb 2006, Aubrey wrote:
>
> I'm a newbie of git. I have a question about how to generate a patch by git.
> I want to make a patch againt git repository HEAD. So in my local
> tree, I do the command:
>
> git diff -p > my.patch
You don't need the "-p" - it's the default for "git diff".
> The file my.patch is generated. But the unchanged files information is
> also included in the patch file. It should be quiet.
It sounds like your index is not synchronized with your file contents.
Have you done "touch" on files? Or edited them, and then edited them back?
If so, "git-update-index --refresh" will re-synchronize your index with
whatever file contents you have.
Linus
^ permalink raw reply
* gitview: Fix the encoding related bug
From: Aneesh Kumar K.V @ 2006-02-27 15:55 UTC (permalink / raw)
To: git, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: 0001-gitview-Fix-the-encoding-related-bug.txt --]
[-- Type: text/plain, Size: 2871 bytes --]
Subject: gitview: Fix the encoding related bug
Get the encoding information from repository and convert it to utf-8 before
passing to gtk.TextBuffer.set_text. gtk.TextBuffer.set_text work only with utf-8
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
contrib/gitview/gitview | 20 ++++++++++++++------
1 files changed, 14 insertions(+), 6 deletions(-)
0900cf4b80aa18e314aa487d84189b8237d088e7
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index 4e3847d..1d042e3 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -391,7 +391,7 @@ class DiffWindow:
sourceview.show()
- def set_diff(self, commit_sha1, parent_sha1):
+ def set_diff(self, commit_sha1, parent_sha1, encoding):
"""Set the differences showed by this window.
Compares the two trees and populates the window with the
differences.
@@ -401,7 +401,7 @@ class DiffWindow:
return
fp = os.popen("git diff-tree -p " + parent_sha1 + " " + commit_sha1)
- self.buffer.set_text(fp.read())
+ self.buffer.set_text(unicode(fp.read(), encoding).encode('utf-8'))
fp.close()
self.window.show()
@@ -430,6 +430,7 @@ class GitView:
self.window.set_border_width(0)
self.window.set_title("Git repository browser")
+ self.get_encoding()
self.get_bt_sha1()
# Use three-quarters of the screen by default
@@ -468,6 +469,13 @@ class GitView:
self.bt_sha1[sha1].append(name)
fp.close()
+ def get_encoding(self):
+ fp = os.popen("git repo-config --get i18n.commitencoding")
+ self.encoding=string.strip(fp.readline())
+ fp.close()
+ if (self.encoding == ""):
+ self.encoding = "utf-8"
+
def construct(self):
"""Construct the window contents."""
@@ -683,7 +691,7 @@ class GitView:
self.revid_label.set_text(revid_label)
self.committer_label.set_text(committer)
self.timestamp_label.set_text(timestamp)
- self.message_buffer.set_text(message)
+ self.message_buffer.set_text(unicode(message, self.encoding).encode('utf-8'))
for widget in self.parents_widgets:
self.table.remove(widget)
@@ -728,7 +736,7 @@ class GitView:
button.set_relief(gtk.RELIEF_NONE)
button.set_sensitive(True)
button.connect("clicked", self._show_clicked_cb,
- commit.commit_sha1, parent_id)
+ commit.commit_sha1, parent_id, self.encoding)
hbox.pack_start(button, expand=False, fill=True)
button.show()
@@ -967,10 +975,10 @@ class GitView:
self.treeview.grab_focus()
- def _show_clicked_cb(self, widget, commit_sha1, parent_sha1):
+ def _show_clicked_cb(self, widget, commit_sha1, parent_sha1, encoding):
"""Callback for when the show button for a parent is clicked."""
window = DiffWindow()
- window.set_diff(commit_sha1, parent_sha1)
+ window.set_diff(commit_sha1, parent_sha1, encoding)
self.treeview.grab_focus()
if __name__ == "__main__":
--
1.2.3.g2cf3-dirty
^ permalink raw reply related
* Re: Quick question: how to generate a patch?
From: Andreas Ericsson @ 2006-02-27 15:28 UTC (permalink / raw)
To: Aubrey; +Cc: git
In-Reply-To: <6d6a94c50602270657m453cc581p6ec290c20879de25@mail.gmail.com>
Aubrey wrote:
> Hi all,
>
> I'm a newbie of git. I have a question about how to generate a patch by git.
> I want to make a patch againt git repository HEAD. So in my local
> tree, I do the command:
>
> git diff -p > my.patch
>
> The file my.patch is generated. But the unchanged files information is
> also included in the patch file. It should be quiet.
> Was I wrong to use git by this way?
>
> Thanks for your hints.
>
The current best practice involves these steps:
1. Create a topic branch (git checkout -b feature-name)
2. Apply your changes and commit them, preferrably in small and isolated
steps, making sure it compiles after each change.
3. Run "git format-patch origin".
This will result in one or more commit-patches, which contains your
author info, the commit-messages you wrote, the commit-time and all
other such info and ofcourse the diff in unified git format. You can
send those patches on using "git send-email" or apply them using "git am
-k 00*.txt".
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: cg-status and empty directories
From: Andreas Ericsson @ 2006-02-27 15:22 UTC (permalink / raw)
To: Jim MacBaine; +Cc: git
In-Reply-To: <3afbacad0602270643k9fdd255w8f3769ad77c54e65@mail.gmail.com>
Jim MacBaine wrote:
> Hello,
>
> Short story: Recently I noticed a change in the way, cogito handles
> empty directories. Before, empty directories have been silently
> ignored. Now cg-status always lists the status of empty directories as
> unknown, but it still refuses to add them. If there is a good reason
> for this behaviour, can someone enlighten me?
>
> Long story: I'm using cogito to track and distribute changes on the
> /etc directories of a few (almost) identical machines. Whenever I
> install a package which modifies somthing in /etc, I commit those
> changes. But with cg-status reporting all the empty directories as
> "unknown", my brain needs a long time to parse the list and find the
> really unknown files which shall be put under version control.
>
> Many packages put empty directories under /etc, and although only a
> few of those directories are actually needed, the automatic removal of
> those packages will fail if I remove the empty directories manually.
> Equally, the removal will fail, if I put a .placeholder file into
> those direrectories and cg-add it. Is there a simple way out?
>
I'm afraid not.
You should also note that git doesn't track permissions exactly. It just
notices an execution bit and uses it to determine if it should write the
working tree using (0666 ^ umask) or (0777 ^ umask). This makes it
fairly unsuitable for /etc tracking unless you add some sort of
permission restoring thing to it.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: the war on trailing whitespace
From: Randal L. Schwartz @ 2006-02-27 15:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Peter Hagervall, Andreas Ericsson, git
In-Reply-To: <Pine.LNX.4.63.0602271539160.4371@wbgn013.biozentrum.uni-wuerzburg.de>
>>>>> "Johannes" == Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
Johannes> Exactly. That is what Andreas is saying: if you change a line which
Johannes> consists only of trailing whitespace to an empty line, it breaks python
Johannes> (or formatting).
[insert standard rant about Python treating invisible things significantly,
which is the prime counter-rant to people saying Perl looks like line noise]
[chuckling]
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!
^ permalink raw reply
* Quick question: how to generate a patch?
From: Aubrey @ 2006-02-27 14:57 UTC (permalink / raw)
To: git
Hi all,
I'm a newbie of git. I have a question about how to generate a patch by git.
I want to make a patch againt git repository HEAD. So in my local
tree, I do the command:
git diff -p > my.patch
The file my.patch is generated. But the unchanged files information is
also included in the patch file. It should be quiet.
Was I wrong to use git by this way?
Thanks for your hints.
Regards,
-Aubrey
^ permalink raw reply
* cg-status and empty directories
From: Jim MacBaine @ 2006-02-27 14:43 UTC (permalink / raw)
To: git
Hello,
Short story: Recently I noticed a change in the way, cogito handles
empty directories. Before, empty directories have been silently
ignored. Now cg-status always lists the status of empty directories as
unknown, but it still refuses to add them. If there is a good reason
for this behaviour, can someone enlighten me?
Long story: I'm using cogito to track and distribute changes on the
/etc directories of a few (almost) identical machines. Whenever I
install a package which modifies somthing in /etc, I commit those
changes. But with cg-status reporting all the empty directories as
"unknown", my brain needs a long time to parse the list and find the
really unknown files which shall be put under version control.
Many packages put empty directories under /etc, and although only a
few of those directories are actually needed, the automatic removal of
those packages will fail if I remove the empty directories manually.
Equally, the removal will fail, if I put a .placeholder file into
those direrectories and cg-add it. Is there a simple way out?
Regards,
Jim
^ permalink raw reply
* Re: the war on trailing whitespace
From: Johannes Schindelin @ 2006-02-27 14:40 UTC (permalink / raw)
To: Peter Hagervall; +Cc: Andreas Ericsson, git
In-Reply-To: <20060227143147.GA12196@brainysmurf.cs.umu.se>
Hi,
On Mon, 27 Feb 2006, Peter Hagervall wrote:
> On Mon, Feb 27, 2006 at 03:10:55PM +0100, Andreas Ericsson wrote:
> > So in essence, a multi-line statement is closed when a completely empty
> > line is found, which means that making git internals recognize and strip
> > such lines will result in Python code never being manageable by git.
> >
>
> I believe completely empty lines are to be left untouched. The war is on
> trailing whitespace.
Exactly. That is what Andreas is saying: if you change a line which
consists only of trailing whitespace to an empty line, it breaks python
(or formatting).
Hth,
Dscho
^ permalink raw reply
* Re: the war on trailing whitespace
From: Peter Hagervall @ 2006-02-27 14:31 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Uwe Zeisberger, git
In-Reply-To: <4403086F.5040704@op5.se>
On Mon, Feb 27, 2006 at 03:10:55PM +0100, Andreas Ericsson wrote:
> So in essence, a multi-line statement is closed when a completely empty
> line is found, which means that making git internals recognize and strip
> such lines will result in Python code never being manageable by git.
>
I believe completely empty lines are to be left untouched. The war is on
trailing whitespace.
/ Peter
--
Peter Hagervall......................email: hager@cs.umu.se
Department of Computing Science........tel: +46(0)90 786 7018
University of Umeå, SE-901 87 Umeå.....fax: +46(0)90 786 6126
^ permalink raw reply
* Re: the war on trailing whitespace
From: Andreas Ericsson @ 2006-02-27 14:10 UTC (permalink / raw)
To: Uwe Zeisberger; +Cc: git
In-Reply-To: <20060227133124.GA8794@informatik.uni-freiburg.de>
Uwe Zeisberger wrote:
> Hello,
>
> Andreas Ericsson wrote:
>
>>I think the question is whether completely empty lines are also ignored
>>by Python, or if they start a new block of code. Whatever the case, it
>>must hold true for both 2.3 and 2.4.
>
> see
> http://www.python.org/doc/2.2.3/ref/blank-lines.html
> http://www.python.org/doc/2.3.5/ref/blank-lines.html
> http://www.python.org/doc/2.4.2/ref/blank-lines.html
>
So in essence, a multi-line statement is closed when a completely empty
line is found, which means that making git internals recognize and strip
such lines will result in Python code never being manageable by git.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: the war on trailing whitespace
From: Uwe Zeisberger @ 2006-02-27 13:31 UTC (permalink / raw)
To: git
In-Reply-To: <4402E56D.4010606@op5.se>
Hello,
Andreas Ericsson wrote:
> I think the question is whether completely empty lines are also ignored
> by Python, or if they start a new block of code. Whatever the case, it
> must hold true for both 2.3 and 2.4.
see
http://www.python.org/doc/2.2.3/ref/blank-lines.html
http://www.python.org/doc/2.3.5/ref/blank-lines.html
http://www.python.org/doc/2.4.2/ref/blank-lines.html
Best regards
Uwe
--
Uwe Zeisberger
http://www.google.com/search?q=gravity+on+earth%3D
^ permalink raw reply
* [PATCH] git-format-patch: Always add a blank line between headers and body.
From: Alexandre Julliard @ 2006-02-27 13:09 UTC (permalink / raw)
To: git
If the second line of the commit message isn't empty, git-format-patch
needs to add an empty line in order to generate a properly formatted
mail. Otherwise git-rebase drops the rest of the commit message.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
---
git-format-patch.sh | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
dcd0ed6ced98990c92a32416c0acc3ec298f5b91
diff --git a/git-format-patch.sh b/git-format-patch.sh
index eb75de4..2bd2639 100755
--- a/git-format-patch.sh
+++ b/git-format-patch.sh
@@ -174,7 +174,7 @@ titleScript='
process_one () {
perl -w -e '
my ($keep_subject, $num, $signoff, $commsg) = @ARGV;
-my ($signoff_pattern, $done_header, $done_subject, $signoff_seen,
+my ($signoff_pattern, $done_header, $done_subject, $done_separator, $signoff_seen,
$last_was_signoff);
if ($signoff) {
@@ -228,6 +228,11 @@ while (<FH>) {
$done_subject = 1;
next;
}
+ unless ($done_separator) {
+ print "\n";
+ $done_separator = 1;
+ next if (/^$/);
+ }
$last_was_signoff = 0;
if (/Signed-off-by:/i) {
--
1.2.3.gb348-dirty
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply related
* Re: [PATCH] Handle branch names with slashes
From: Karl Hasselström @ 2006-02-27 13:09 UTC (permalink / raw)
To: catalin.marinas; +Cc: Sam Vilain, git
In-Reply-To: <1141043391.3438.66.camel@pc1117>
On 2006-02-27 12:29:51 +0000, Catalin Marinas wrote:
> On Mon, 2006-02-27 at 13:11 +0100, Karl Hasselström wrote:
>
> > There was a bug here after all: I just tried "stg pick
> > multi@kha/patches" (to pick a patch named "multi" from the branch
> > "kha/patches"), and StGIT tried to pick the patch from branch
> > "kha".
>
> I haven't applied your patch yet (too busy to properly review it).
And as I just demonstrated, it certainly needed reviewing! (Actually,
I believe I said that back when I posted the patch, too.)
> > Looking closer, I realized that the complete patch specification
> > syntax is "patchname@branchname/bottom", not
> > "patchname/bottom@branchname" as I had assumed. This is obviously
> > hard to reconcile with branch names containing /.
>
> I don't have any strong opinion on either. Maybe we should use the
> latter if it makes things easier for supporting branch names with
> /'s.
The problem is that the current from is better (bottom is a modifier
to patch@branch, not just patch). And using the other form will break
when someone decides that patches with slashes in their names are a
good idea (not a joke).
Perhaps change /bottom to #bottom (making the complete form
patchname@branchname#bottom), and for backward compatibility accept
patchname@branchname/bottom as well when no branch called
"branchname/bottom" exists.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: Teach the "git" command to handle some commands internally
From: Michal Ostrowski @ 2006-02-27 12:59 UTC (permalink / raw)
To: Junio C Hamano
Cc: Linus Torvalds, Git Mailing List, Andreas Ericsson, Alex Riesen
In-Reply-To: <7vy7zx65v0.fsf@assigned-by-dhcp.cox.net>
On Sun, 2006-02-26 at 15:46 -0800, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > On Sun, 26 Feb 2006, Junio C Hamano wrote:
> >>
> >> > There's one other change: the search order for external programs is
> >> > modified slightly, so that the first entry remains GIT_EXEC_DIR, but the
> >> > second entry is the same directory as the git wrapper itself was executed
> >> > out of - if we can figure it out from argv[0], of course.
> >>
> >> I am not sure about this part, though.
> >
> > Well, what it means is that _if_ you install all your "git" binaries in
> > some directory that is not in your patch and is not GIT_EXEC_DIR, they
> > will still magically work, assuming you don't do something strange.
>
> I understood that part. I was wondering if this change defeats
> what Michal (you sensibly CC'ed your message to) wanted to do
> earlier, going great length trying to avoid mucking with PATH
> and "where-ever git itself is found" in the last round. After
> reviewing the change in 77cb17 commit, I realize my worry was
> unfounded.
The changes seem reasonable for now. We can't avoid mucking with PATH
as long as we are going to be running shell scripts that depend on PATH
to invoke "git-xxx" or even "git xxx". I don't seen any easy solution
to this that would not involve changing every script (albeit
mechanically) and would not be prone to lapses in discipline.
Any solution to this original problem (i.e. a special "PATH" for "git*")
would seem to be applicable to the behavior this patch introduces.
--
Michal Ostrowski <mostrows@watson.ibm.com>
^ permalink raw reply
* [PATCH 2/2] combine-diff: Honour -z option correctly.
From: Mark Wooding @ 2006-02-27 12:52 UTC (permalink / raw)
To: git
In-Reply-To: <20060227124815.25144.83101.stgit@metalzone.distorted.org.uk>
From: Mark Wooding <mdw@distorted.org.uk>
Combined diffs don't null terminate things in the same way as standard
diffs. This is presumably wrong.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
---
combine-diff.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index 984103e..a23894d 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -726,7 +726,7 @@ static int show_patch_diff(struct combin
if (header) {
shown_header++;
- puts(header);
+ printf("%s%c", header, opt->line_termination);
}
printf("diff --%s ", dense ? "cc" : "combined");
if (quote_c_style(elem->path, NULL, NULL, 0))
@@ -799,7 +799,7 @@ static void show_raw_diff(struct combine
inter_name_termination = 0;
if (header)
- puts(header);
+ printf("%s%c", header, line_termination);
for (i = 0; i < num_parent; i++) {
if (p->parent[i].mode)
^ permalink raw reply related
* [PATCH 1/2] combine-diff: Honour --full-index.
From: Mark Wooding @ 2006-02-27 12:52 UTC (permalink / raw)
To: git
In-Reply-To: <20060227124815.25144.83101.stgit@metalzone.distorted.org.uk>
From: Mark Wooding <mdw@distorted.org.uk>
For some reason, combined diffs don't honour the --full-index flag when
emitting patches. Fix this.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
---
combine-diff.c | 10 ++++++----
1 files changed, 6 insertions(+), 4 deletions(-)
diff --git a/combine-diff.c b/combine-diff.c
index d812600..984103e 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -621,7 +621,8 @@ static void reuse_combine_diff(struct sl
}
static int show_patch_diff(struct combine_diff_path *elem, int num_parent,
- int dense, const char *header)
+ int dense, const char *header,
+ struct diff_options *opt)
{
unsigned long size, cnt, lno;
char *result, *cp, *ep;
@@ -631,6 +632,7 @@ static int show_patch_diff(struct combin
char ourtmp_buf[TMPPATHLEN];
char *ourtmp = ourtmp_buf;
int working_tree_file = !memcmp(elem->sha1, null_sha1, 20);
+ int abbrev = opt->full_index ? 40 : DEFAULT_ABBREV;
/* Read the result of merge first */
if (!working_tree_file) {
@@ -735,10 +737,10 @@ static int show_patch_diff(struct combin
printf("index ");
for (i = 0; i < num_parent; i++) {
abb = find_unique_abbrev(elem->parent[i].sha1,
- DEFAULT_ABBREV);
+ abbrev);
printf("%s%s", i ? "," : "", abb);
}
- abb = find_unique_abbrev(elem->sha1, DEFAULT_ABBREV);
+ abb = find_unique_abbrev(elem->sha1, abbrev);
printf("..%s\n", abb);
if (mode_differs) {
@@ -862,7 +864,7 @@ int show_combined_diff(struct combine_di
default:
case DIFF_FORMAT_PATCH:
- return show_patch_diff(p, num_parent, dense, header);
+ return show_patch_diff(p, num_parent, dense, header, opt);
}
}
^ permalink raw reply related
* [PATCH 0/2] combine-diff consistency fixes
From: Mark Wooding @ 2006-02-27 12:48 UTC (permalink / raw)
To: git
The output of git diff-tree --cc on a merge is not consistent with its
output for a normal commit. In particular:
* the index lines on a combined diff are abbreviated even if
--full-index is given, and
* the headers on a combined diff are not null terminated, even if -z
is given.
For example, run
git-diff-tree --cc -z --full-index f0b0af1b04f558b684cae2a3b805ca4bab84d45f
-- [mdw]
^ permalink raw reply
* Re: [PATCH] Handle branch names with slashes
From: Catalin Marinas @ 2006-02-27 12:29 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Sam Vilain, git
In-Reply-To: <20060227121108.GA22398@diana.vm.bytemark.co.uk>
On Mon, 2006-02-27 at 13:11 +0100, Karl Hasselström wrote:
> There was a bug here after all: I just tried "stg pick
> multi@kha/patches" (to pick a patch named "multi" from the branch
> "kha/patches"), and StGIT tried to pick the patch from branch "kha".
I haven't applied your patch yet (too busy to properly review it).
> Looking closer, I realized that the complete patch specification
> syntax is "patchname@branchname/bottom", not
> "patchname/bottom@branchname" as I had assumed. This is obviously hard
> to reconcile with branch names containing /.
I don't have any strong opinion on either. Maybe we should use the
latter if it makes things easier for supporting branch names with /'s.
--
Catalin
^ permalink raw reply
* Re: [PATCH] Handle branch names with slashes
From: Karl Hasselström @ 2006-02-27 12:11 UTC (permalink / raw)
To: Sam Vilain; +Cc: Catalin Marinas, git
In-Reply-To: <20060217042108.GB28114@diana.vm.bytemark.co.uk>
On 2006-02-17 05:21:08 +0100, Karl Hasselström wrote:
> On 2006-02-17 16:01:10 +1300, Sam Vilain wrote:
>
> > Karl Hasselström wrote:
> >
> > > Let StGIT grok branch names with slashes in them. It used to
> > > fall flat on its face when confronted with them.
> > >
> > > I think I've covered all, or at least most cases, but there are
> > > probably some bugs left if you look hard enough.
> >
> > Does `stgit -r patchname/bottom` still work?
>
> Yes (if you mean 'stg diff -r ... ' :-). It's just branches that can
> have slashes in their names, not patches.
There was a bug here after all: I just tried "stg pick
multi@kha/patches" (to pick a patch named "multi" from the branch
"kha/patches"), and StGIT tried to pick the patch from branch "kha".
Looking closer, I realized that the complete patch specification
syntax is "patchname@branchname/bottom", not
"patchname/bottom@branchname" as I had assumed. This is obviously hard
to reconcile with branch names containing /.
Thoughts?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: the war on trailing whitespace
From: Johannes Schindelin @ 2006-02-27 11:55 UTC (permalink / raw)
To: Adrien Beau; +Cc: git
In-Reply-To: <94fc236b0602270326s3079d737l102d5728d59f0c98@mail.gmail.com>
On Mon, 27 Feb 2006, Adrien Beau wrote:
> A logical line that contains only spaces and tabs is ignored by
> Python. (All the "dirty" lines in git-merge-recursive.py are such
> lines.)
>
> Hope this helps,
It does.
Thanks,
Dscho
^ permalink raw reply
* Re: the war on trailing whitespace
From: Andreas Ericsson @ 2006-02-27 11:41 UTC (permalink / raw)
To: Adrien Beau
Cc: Johannes Schindelin, MIke Galbraith, Dave Jones, Linus Torvalds,
Andrew Morton, junkio, git
In-Reply-To: <94fc236b0602270326s3079d737l102d5728d59f0c98@mail.gmail.com>
Adrien Beau wrote:
> On 2/27/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
>>there is a good reason not to enable the no-whitespace-at-eol checking in
>>pre-commit by default (at least for *all* files) for git development:
>>
>> Python.
>>
>>Just do a "/ $" in git-merge-recursive.py. These whitespaces are not an
>>error, but a syntactic *requirement*.
>
>
> No, they aren't.
>
> A logical line that contains only spaces and tabs is ignored by
> Python. (All the "dirty" lines in git-merge-recursive.py are such
> lines.)
>
I think the question is whether completely empty lines are also ignored
by Python, or if they start a new block of code. Whatever the case, it
must hold true for both 2.3 and 2.4.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: the war on trailing whitespace
From: Adrien Beau @ 2006-02-27 11:26 UTC (permalink / raw)
To: Johannes Schindelin
Cc: MIke Galbraith, Dave Jones, Linus Torvalds, Andrew Morton, junkio,
git
In-Reply-To: <Pine.LNX.4.63.0602271004130.5937@wbgn013.biozentrum.uni-wuerzburg.de>
On 2/27/06, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> there is a good reason not to enable the no-whitespace-at-eol checking in
> pre-commit by default (at least for *all* files) for git development:
>
> Python.
>
> Just do a "/ $" in git-merge-recursive.py. These whitespaces are not an
> error, but a syntactic *requirement*.
No, they aren't.
A logical line that contains only spaces and tabs is ignored by
Python. (All the "dirty" lines in git-merge-recursive.py are such
lines.)
Besides, spaces, tabs and newlines can be used interchangeably to
separate tokens, so trailing whitespace is never *required*.
Hope this helps,
Adrien
^ permalink raw reply
* Re: the war on trailing whitespace
From: Andrew Morton @ 2006-02-27 9:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: efault, davej, torvalds, junkio, git
In-Reply-To: <Pine.LNX.4.63.0602271004130.5937@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> Hi,
>
> there is a good reason not to enable the no-whitespace-at-eol checking in
> pre-commit by default (at least for *all* files) for git development:
>
> Python.
That's not a good reason. People will discover that git has started
shouting at them and they'll work out how to make it stop.
The probem is getting C users to turn the check on, not in getting python
users to turn it off.
^ permalink raw reply
* Re: NT directory traversal speed on 25K files on Cygwin
From: Andreas Ericsson @ 2006-02-27 9:19 UTC (permalink / raw)
To: git; +Cc: Christopher Faylor, git
In-Reply-To: <20060226231701.GA11961@nospam.com>
Rutger Nijlunsing wrote:
> On Sun, Feb 26, 2006 at 02:55:52PM -0500, Christopher Faylor wrote:
>
>>On Thu, Feb 23, 2006 at 03:07:07PM +0100, Alex Riesen wrote:
>>
>>>filesystem is slow and locked down, and exec-attribute is NOT really
>>>useful even on NTFS (it is somehow related to execute permission and
>>>open files. I still cannot figure out how exactly are they related).
>>
>>Again, it's not clear if you're talking about Windows or Cygwin but
>>under Cygwin, in the default configuration, the exec attribute means the
>>same thing to cygwin as it does to linux.
>
>
> I don't know about native Windows speed, but comparing NutCracker with
> Cygwin on a simple 'find . | wc -l' already gives a clue that looking
> at Cygwin to benchmark NT file inspection IO will give a skewed
> picture:
>
Well, naturally. Cygwin is a userland implementation of a sane
filesystem on top of a less sane one. File IO is bound to be slower when
one FS is emulated on top of another. I think cygwin users are aware of
this and simply accept the speed-for-sanity tradeoff. I know I would.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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