* 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
* [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: 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
* 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: 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: 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
* 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
* 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
* 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
* 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: 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
* 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: 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
* 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: Aubrey @ 2006-02-27 16:18 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602270801280.22647@g5.osdl.org>
> > 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.
>
No, what I did was just "git clone" one repository to my local directory.
And entered the local directory to modify one file I wanted.
Then I run "git diff > my.patch". The "my.patch" was supposed to
contain one file diff information. But it contained the all the files,
including which were not changed.
Thanks to reply. I''ll try to Andreas's suggestion.
Regards,
-Aubrey
^ permalink raw reply
* Re: the war on trailing whitespace
From: Adrien Beau @ 2006-02-27 16:22 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Uwe Zeisberger, git
In-Reply-To: <4403086F.5040704@op5.se>
On 2/27/06, Andreas Ericsson <ae@op5.se> 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.
Incorrect. This is only the case in the *interactive* interpreter in
the standard implementation. For source code in general, quoting the
Python Reference Manual:
"A logical line that contains only spaces, tabs, formfeeds and
possibly a comment, is ignored (i.e., no NEWLINE token is generated)."
So such lines, whether completely empty or only apparently so (i.e.
dirty), are ignored, and can be safely cleaned-up.
Adrien
^ permalink raw reply
* Re: Quick question: how to generate a patch?
From: Linus Torvalds @ 2006-02-27 16:32 UTC (permalink / raw)
To: Aubrey; +Cc: git
In-Reply-To: <6d6a94c50602270818k5f82bb8ft68a19899db3db636@mail.gmail.com>
On Tue, 28 Feb 2006, Aubrey wrote:
>
> No, what I did was just "git clone" one repository to my local directory.
> And entered the local directory to modify one file I wanted.
> Then I run "git diff > my.patch". The "my.patch" was supposed to
> contain one file diff information. But it contained the all the files,
> including which were not changed.
It really should "just have worked". Can you show what the diff actually
looked like, and your exact command history?
If it was something like
git clone remote-repo localdir
cd localdir
vi somefile
git diff
then you did everything right, and if it gives any diff other than your
changes to "somefile", something is buggy. Need more info.
Does "git diff" and "git diff HEAD" give different results, btw?
Linus
^ permalink raw reply
* Re: the war on trailing whitespace
From: Uwe Zeisberger @ 2006-02-27 16:37 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4403086F.5040704@op5.se>
Andreas Ericsson wrote:
> 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,
Wrong.
A logical line that contains only spaces, tabs, formfeeds and possibly a
comment, is ignored (i.e., no NEWLINE token is generated). During
interactive input of statements, handling of a blank line may differ
depending on the implementation of the read-eval-print loop. In the
standard implementation, an entirely blank logical line (i.e. one
containing not even whitespace or a comment) terminates a multi-line
statement.
To translate that to python:
if not interactive:
a line only containing whitespace is ignored.
else:
if standard implementation:
empty line terminates multi-line statement
else:
dependent on implementation
i.e. In scripts, lines containing only (zero or more) whitespaces are
ignored.
hth
Uwe
--
Uwe Zeisberger
Set the I_WANT_A_BROKEN_PS environment variable to force BSD syntax ...
-- manpage of procps
^ permalink raw reply
* Re: the war on trailing whitespace
From: Andreas Ericsson @ 2006-02-27 16:41 UTC (permalink / raw)
To: Uwe Zeisberger; +Cc: git
In-Reply-To: <20060227163709.GA12538@informatik.uni-freiburg.de>
Uwe Zeisberger wrote:
> Andreas Ericsson wrote:
>
>>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,
>
> Wrong.
>
> i.e. In scripts, lines containing only (zero or more) whitespaces are
> ignored.
>
I stand corrected. Thrice, even. Voi, voi... :)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] First cut at libifying revlist generation
From: Linus Torvalds @ 2006-02-27 16:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0602262119200.22647@g5.osdl.org>
On Sun, 26 Feb 2006, Linus Torvalds wrote:
>
> I suspect that the simplest fix is to just move "limited" into the "revs"
> structure, the way I did pretty much everything else. That way nothing
> really changes: we'll have the exact same logic, the flag just moved
> around.
Here's a cleanup patch that does that. It also moves "unpacked" (and the
flag parsing) into rev_info, since that actually does affect the revision
walker too, and thus logically belongs there.
If you prefer, I can generate a totally re-done patch that combines all
the fixes so far.
Linus
----
diff-tree d33c6e5017d52d36f8da44162c0d87899efd247c (from 4b0fd13e13f49fa73ddd03a69f7d2ad1109139d4)
Author: Linus Torvalds <torvalds@osdl.org>
Date: Mon Feb 27 08:50:26 2006 -0800
Fix rev-list "limited" handling
Also, move "unpacked" into the rev_info structure, where it logically belongs.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
diff --git a/rev-list.c b/rev-list.c
index e9e371c..2e80930 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -41,7 +41,6 @@ static const char rev_list_usage[] =
struct rev_info revs;
-static int unpacked = 0;
static int bisect_list = 0;
static int verbose_header = 0;
static int abbrev = DEFAULT_ABBREV;
@@ -572,7 +571,7 @@ static struct commit_list *limit_list(st
if (revs.max_age != -1 && (commit->date < revs.max_age))
obj->flags |= UNINTERESTING;
- if (unpacked && has_sha1_pack(obj->sha1))
+ if (revs.unpacked && has_sha1_pack(obj->sha1))
obj->flags |= UNINTERESTING;
add_parents_to_list(commit, &list);
if (obj->flags & UNINTERESTING) {
@@ -595,7 +594,7 @@ static struct commit_list *limit_list(st
int main(int argc, const char **argv)
{
struct commit_list *list;
- int i, limited = 0;
+ int i;
argc = setup_revisions(argc, argv, &revs);
@@ -655,11 +654,6 @@ int main(int argc, const char **argv)
bisect_list = 1;
continue;
}
- if (!strcmp(arg, "--unpacked")) {
- unpacked = 1;
- limited = 1;
- continue;
- }
if (!strcmp(arg, "--merge-order")) {
merge_order = 1;
continue;
@@ -673,34 +667,25 @@ int main(int argc, const char **argv)
}
list = revs.commits;
- if (list && list->next)
- limited = 1;
-
- if (revs.topo_order)
- limited = 1;
if (!list &&
(!(revs.tag_objects||revs.tree_objects||revs.blob_objects) && !revs.pending_objects))
usage(rev_list_usage);
- if (revs.paths) {
- limited = 1;
+ if (revs.paths)
diff_tree_setup_paths(revs.paths);
- }
- if (revs.max_age || revs.min_age)
- limited = 1;
save_commit_buffer = verbose_header;
track_object_refs = 0;
if (!merge_order) {
sort_by_date(&list);
- if (list && !limited && revs.max_count == 1 &&
+ if (list && !revs.limited && revs.max_count == 1 &&
!revs.tag_objects && !revs.tree_objects && !revs.blob_objects) {
show_commit(list->item);
return 0;
}
- if (limited)
+ if (revs.limited)
list = limit_list(list);
if (revs.topo_order)
sort_in_topological_order(&list, revs.lifo);
diff --git a/revision.c b/revision.c
index 17dbf9a..0422593 100644
--- a/revision.c
+++ b/revision.c
@@ -143,8 +143,10 @@ static struct commit *get_commit_referen
object->flags |= flags;
if (parse_commit(commit) < 0)
die("unable to parse commit %s", name);
- if (flags & UNINTERESTING)
+ if (flags & UNINTERESTING) {
mark_parents_uninteresting(commit);
+ revs->limited = 1;
+ }
return commit;
}
@@ -255,10 +257,12 @@ int setup_revisions(int argc, const char
}
if (!strncmp(arg, "--max-age=", 10)) {
revs->max_age = atoi(arg + 10);
+ revs->limited = 1;
continue;
}
if (!strncmp(arg, "--min-age=", 10)) {
revs->min_age = atoi(arg + 10);
+ revs->limited = 1;
continue;
}
if (!strcmp(arg, "--all")) {
@@ -277,11 +281,13 @@ int setup_revisions(int argc, const char
}
if (!strcmp(arg, "--topo-order")) {
revs->topo_order = 1;
+ revs->limited = 1;
continue;
}
if (!strcmp(arg, "--date-order")) {
revs->lifo = 0;
revs->topo_order = 1;
+ revs->limited = 1;
continue;
}
if (!strcmp(arg, "--dense")) {
@@ -309,6 +315,11 @@ int setup_revisions(int argc, const char
revs->edge_hint = 1;
continue;
}
+ if (!strcmp(arg, "--unpacked")) {
+ revs->unpacked = 1;
+ revs->limited = 1;
+ continue;
+ }
*unrecognized++ = arg;
left++;
continue;
@@ -365,6 +376,8 @@ int setup_revisions(int argc, const char
commit = get_commit_reference(revs, def, sha1, 0);
add_one_commit(commit, revs);
}
+ if (revs->paths)
+ revs->limited = 1;
*unrecognized = NULL;
return left;
}
diff --git a/revision.h b/revision.h
index 5170ac4..a22f198 100644
--- a/revision.h
+++ b/revision.h
@@ -21,7 +21,9 @@ struct rev_info {
tag_objects:1,
tree_objects:1,
blob_objects:1,
- edge_hint:1;
+ edge_hint:1,
+ limited:1,
+ unpacked:1;
/* special limits */
int max_count;
^ permalink raw reply related
* Re: Quick question: how to generate a patch?
From: Aubrey @ 2006-02-27 17:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0602270830330.22647@g5.osdl.org>
> It really should "just have worked". Can you show what the diff actually
> looked like, and your exact command history?
=================================================================
aubrey@linux:/checkout/uboot/patch/work/drivers> git diff
----snip----
diff --git a/drivers/sk98lin/skxmac2.c b/drivers/sk98lin/skxmac2.c
diff --git a/drivers/sk98lin/u-boot_compat.h b/drivers/sk98lin/u-boot_compat.h
diff --git a/drivers/sk98lin/uboot_drv.c b/drivers/sk98lin/uboot_drv.c
diff --git a/drivers/sk98lin/uboot_skb.c b/drivers/sk98lin/uboot_skb.c
diff --git a/drivers/sl811.h b/drivers/sl811.h
diff --git a/drivers/sl811_usb.c b/drivers/sl811_usb.c
diff --git a/drivers/sm501.c b/drivers/sm501.c
diff --git a/drivers/smc91111.c b/drivers/smc91111.c
diff --git a/drivers/smc91111.h b/drivers/smc91111.h
index cf08582..e5742ba 100644
--- a/drivers/smc91111.h
+++ b/drivers/smc91111.h
@@ -185,6 +185,8 @@ typedef unsigned long int dword;
#ifdef CONFIG_ADNPESC1
#define SMC_inw(r) (*((volatile word
*)(SMC_BASE_ADDRESS+((r)<<1))))
+#elif CONFIG_BLACKFIN
+#define SMC_inw(r) ({ word __v = (*((volatile word
*)(SMC_BASE_ADDRESS+(r)))); __builtin_bfin_ssync(); __v;})
#else
#define SMC_inw(r) (*((volatile word *)(SMC_BASE_ADDRESS+(r))))
#endif
@@ -192,6 +194,8 @@ typedef unsigned long int dword;
#ifdef CONFIG_ADNPESC1
#define SMC_outw(d,r) (*((volatile word
*)(SMC_BASE_ADDRESS+((r)<<1))) = d)
+#elif CONFIG_BLACKFIN
+#define SMC_outw(d,r) {(*((volatile word *)(SMC_BASE_ADDRESS+(r)))
= d);__builtin_bfin_ssync();}
#else
#define SMC_outw(d,r) (*((volatile word *)(SMC_BASE_ADDRESS+(r))) = d)
#endif
@@ -232,6 +236,8 @@ typedef unsigned long int dword;
#ifdef CONFIG_XSENGINE
#define SMC_inl(r) (*((volatile dword *)(SMC_BASE_ADDRESS+(r<<1))))
+#elif CONFIG_BLACKFIN
+#define SMC_inl(r) ({ dword __v = (*((volatile dword
*)(SMC_BASE_ADDRESS+(r))));__builtin_bfin_ssync(); __v;})
#else
#define SMC_inl(r) (*((volatile dword *)(SMC_BASE_ADDRESS+(r))))
#endif
@@ -247,6 +253,8 @@ typedef unsigned long int dword;
#ifdef CONFIG_XSENGINE
#define SMC_outl(d,r) (*((volatile dword
*)(SMC_BASE_ADDRESS+(r<<1))) = d)
+#elif CONFIG_BLACKFIN
+#define SMC_outl(d,r) {(*((volatile dword *)(SMC_BASE_ADDRESS+(r)))
= d);__builtin_bfin_ssync();}
#else
#define SMC_outl(d,r) (*((volatile dword
*)(SMC_BASE_ADDRESS+(r))) = d)
#endif
diff --git a/drivers/smiLynxEM.c b/drivers/smiLynxEM.c
diff --git a/drivers/status_led.c b/drivers/status_led.c
diff --git a/drivers/sym53c8xx.c b/drivers/sym53c8xx.c
diff --git a/drivers/ti_pci1410a.c b/drivers/ti_pci1410a.c
diff --git a/drivers/tigon3.c b/drivers/tigon3.c
diff --git a/drivers/tigon3.h b/drivers/tigon3.h
diff --git a/drivers/tsec.c b/drivers/tsec.c
diff --git a/drivers/tsec.h b/drivers/tsec.h
----snip----
=================================================================
>
> If it was something like
>
> git clone remote-repo localdir
> cd localdir
> vi somefile
> git diff
>
Yes, exactly right.
> then you did everything right, and if it gives any diff other than your
> changes to "somefile", something is buggy. Need more info.
>
> Does "git diff" and "git diff HEAD" give different results, btw?
Yes. the two commands give the same results.
I'm using git-1.2.3
Regards,
-Aubrey
^ permalink raw reply related
* Re: Quick question: how to generate a patch?
From: Andreas Ericsson @ 2006-02-27 17:09 UTC (permalink / raw)
To: Aubrey; +Cc: Linus Torvalds, git
In-Reply-To: <6d6a94c50602270902k2c06aaffw7e70268b0753ef64@mail.gmail.com>
Aubrey wrote:
>>It really should "just have worked". Can you show what the diff actually
>>looked like, and your exact command history?
>
>
>
>>If it was something like
>>
>> git clone remote-repo localdir
>> cd localdir
>> vi somefile
>> git diff
>>
>
> Yes, exactly right.
>
Did you by any chance do chmod -R, chown -R or start an ntp daemon
somewhere in between there (don't know if clock skews will be detected
by git, but...)?
>
>>then you did everything right, and if it gives any diff other than your
>>changes to "somefile", something is buggy. Need more info.
>>
>>Does "git diff" and "git diff HEAD" give different results, btw?
>
>
> Yes. the two commands give the same results.
>
Decidedly odd. What happens when you do "git update-index --refresh" and
then re-run the "git diff > my.patch" thing?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* gitview: Remove trailing white space
From: Aneesh Kumar K.V @ 2006-02-27 17:12 UTC (permalink / raw)
To: git, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 0 bytes --]
[-- Attachment #2: 0002-gitview-Remove-trailing-white-space.txt --]
[-- Type: text/plain, Size: 2725 bytes --]
Subject: gitview: Remove trailing white space
Do the cleanup using Dave jones vim script
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
---
contrib/gitview/gitview | 22 +++++++++++-----------
1 files changed, 11 insertions(+), 11 deletions(-)
69e8209d5152b187dbcf2c09c5db5ae7534a80d5
diff --git a/contrib/gitview/gitview b/contrib/gitview/gitview
index 1d042e3..048caf6 100755
--- a/contrib/gitview/gitview
+++ b/contrib/gitview/gitview
@@ -162,7 +162,7 @@ class CellRendererGraph(gtk.GenericCellR
for item in names:
names_len += len(item)
- width = box_size * (cols + 1 ) + names_len
+ width = box_size * (cols + 1 ) + names_len
height = box_size
# FIXME I have no idea how to use cell_area properly
@@ -261,11 +261,11 @@ class Commit:
children_sha1 = {}
def __init__(self, commit_lines):
- self.message = ""
+ self.message = ""
self.author = ""
- self.date = ""
- self.committer = ""
- self.commit_date = ""
+ self.date = ""
+ self.committer = ""
+ self.commit_date = ""
self.commit_sha1 = ""
self.parent_sha1 = [ ]
self.parse_commit(commit_lines)
@@ -426,7 +426,7 @@ class GitView:
def __init__(self, with_diff=0):
self.with_diff = with_diff
- self.window = gtk.Window(gtk.WINDOW_TOPLEVEL)
+ self.window = gtk.Window(gtk.WINDOW_TOPLEVEL)
self.window.set_border_width(0)
self.window.set_title("Git repository browser")
@@ -878,15 +878,15 @@ class GitView:
# Reset nodepostion
if (last_nodepos > 5):
- last_nodepos = -1
+ last_nodepos = -1
# Add the incomplete lines of the last cell in this
try:
colour = self.colours[commit.commit_sha1]
except KeyError:
self.colours[commit.commit_sha1] = last_colour+1
- last_colour = self.colours[commit.commit_sha1]
- colour = self.colours[commit.commit_sha1]
+ last_colour = self.colours[commit.commit_sha1]
+ colour = self.colours[commit.commit_sha1]
try:
node_pos = self.nodepos[commit.commit_sha1]
@@ -918,7 +918,7 @@ class GitView:
self.colours[parent_id] = last_colour+1
last_colour = self.colours[parent_id]
self.nodepos[parent_id] = last_nodepos+1
- last_nodepos = self.nodepos[parent_id]
+ last_nodepos = self.nodepos[parent_id]
in_line.append((node_pos, self.nodepos[parent_id],
self.colours[parent_id]))
@@ -954,7 +954,7 @@ class GitView:
try:
next_commit = self.commits[index+1]
if (next_commit.commit_sha1 == sha1 and pos != int(pos)):
- # join the line back to the node point
+ # join the line back to the node point
# This need to be done only if we modified it
in_line.append((pos, pos-0.5, self.colours[sha1]))
continue;
--
1.2.3.g2cf3-dirty
^ permalink raw reply related
* Re: Quick question: how to generate a patch?
From: Aubrey @ 2006-02-27 17:18 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Linus Torvalds, git
In-Reply-To: <44033241.6070001@op5.se>
> Did you by any chance do chmod -R, chown -R or start an ntp daemon
> somewhere in between there (don't know if clock skews will be detected
> by git, but...)?
No, I did nothing between "git clone" and "git diff" except changing one file.
>
>
> Decidedly odd. What happens when you do "git update-index --refresh" and
> then re-run the "git diff > my.patch" thing?
>
Yes, "git update-index --refresh" works. After this command, I got what I want.
It's the diff in unified git format.
Regards,
-Aubrey
^ permalink raw reply
* Re: Quick question: how to generate a patch?
From: Linus Torvalds @ 2006-02-27 17:19 UTC (permalink / raw)
To: Aubrey; +Cc: git
In-Reply-To: <6d6a94c50602270902k2c06aaffw7e70268b0753ef64@mail.gmail.com>
On Tue, 28 Feb 2006, Aubrey wrote:
>
> =================================================================
> aubrey@linux:/checkout/uboot/patch/work/drivers> git diff
> ----snip----
> diff --git a/drivers/sk98lin/skxmac2.c b/drivers/sk98lin/skxmac2.c
> diff --git a/drivers/sk98lin/u-boot_compat.h b/drivers/sk98lin/u-boot_compat.h
Ok, this is _definitely_ your index being out of touch with your file
contents.
Run "git-update-index --refresh" and it should be ok.
Now the question is why the index got out-of-kilter with the file contents
in the first place. I used to have all these debug aids to show why git
thought a file had changed, but we've not had any bugs here for a long
long time, so..
The final checkout of the "git clone" should have made sure that the index
is up-to-date.
> > git clone remote-repo localdir
> > cd localdir
> > vi somefile
> > git diff
>
> Yes, exactly right.
>
> > then you did everything right, and if it gives any diff other than your
> > changes to "somefile", something is buggy. Need more info.
> >
> > Does "git diff" and "git diff HEAD" give different results, btw?
>
> Yes. the two commands give the same results.
>
> I'm using git-1.2.3
What OS/filesystem?
The way the index keeps track of files that haven't changed is by checking
the size, the mtime and the ctime of the inode. It also checks the
user/gid and inode number. If you use a filesystem where those might
change (networked?), that might cause this..
Linus
^ 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