* [PATCH] Fix nullpointer exceptions in Quickdiff
From: Robin Rosenberg @ 2008-07-11 21:34 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Marek Zawirski
In-Reply-To: <1215729672-26906-2-git-send-email-robin.rosenberg@dewire.com>
---
I saw some problem when resources were no longer in the worspace, such as during a bisectg.
This one should probably just be squashed into patch 1.
-- robin
diff --git a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitDocument.java b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitDocument.java
index ebed0cf..3724304 100644
--- a/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitDocument.java
+++ b/org.spearce.egit.ui/src/org/spearce/egit/ui/internal/decorators/GitDocument.java
@@ -43,7 +43,10 @@ class GitDocument extends Document implements RepositoryListener {
void populate() throws IOException {
set("");
final IProject project = resource.getProject();
- final String gitPath = RepositoryMapping.getMapping(project).getRepoRelativePath(resource);
+ RepositoryMapping mapping = RepositoryMapping.getMapping(project);
+ if (mapping == null)
+ return;
+ final String gitPath = mapping.getRepoRelativePath(resource);
final Repository repository = getRepository();
repository.addRepositoryChangedListener(this);
String baseline = GitQuickDiffProvider.baseline.get(repository);
@@ -63,7 +66,9 @@ class GitDocument extends Document implements RepositoryListener {
}
void dispose() {
- getRepository().removeRepositoryChangedListener(this);
+ Repository repository = getRepository();
+ if (repository != null)
+ repository.removeRepositoryChangedListener(this);
}
public void refsChanged(final RefsChangedEvent e) {
@@ -81,6 +86,8 @@ class GitDocument extends Document implements RepositoryListener {
private Repository getRepository() {
IProject project = resource.getProject();
RepositoryMapping mapping = RepositoryMapping.getMapping(project);
- return mapping.getRepository();
+ if (mapping != null)
+ return mapping.getRepository();
+ return null;
}
}
--
1.5.6.2.220.g44701
^ permalink raw reply related
* Re: [GitStats] Bling bling or some statistics on the git.git repository
From: Johannes Schindelin @ 2008-07-11 21:39 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git Mailinglist, David Symonds
In-Reply-To: <alpine.DEB.1.00.0807112215050.8950@racer>
Hi,
something else I just realized: you might want to use .mailmap, e.g. to
coalesce the changes of Shawn "O." Pearce correctly.
Ciao,
Dscho
^ permalink raw reply
* Re: Should we discuss Windows-related changes on git@vger.kernel.org?
From: Johannes Schindelin @ 2008-07-11 21:38 UTC (permalink / raw)
To: Steffen Prohaska
Cc: Linus Torvalds, Johannes Sixt, Junio C Hamano, msysGit,
Git Mailing List
In-Reply-To: <0E93411E-745C-4858-999E-F0B7487B48B1@zib.de>
Hi,
On Fri, 11 Jul 2008, Steffen Prohaska wrote:
> On Jul 11, 2008, at 9:40 PM, Johannes Schindelin wrote:
>
> >On Fri, 11 Jul 2008, Linus Torvalds wrote:
> >
> > >- It may well be good to explain to the _real_ git people (eg me)
> > > what the problems in Windows land are, so that we get a first-hand
> > > view into hell, and can maybe take it into account when we make
> > > changes for other things.
> >
> >Wow. I did not think that you were a masochist.
> >
> > >IOW, I think that since 1.6.0 is supposed to have native support for
> > >windows, we should have patches discussed on the regular git list.
> > >The ghetto that is windows can be useful for _user_ discussions,
> > >where a lot of the core git people simply cannot help. But having
> > >development discussions there is bad, I think.
> >
> >We do have development discussions there that do not belong to
> >git@vger. For example, when Hannes reimplemented the utterly broken
> >spawn() implementation of Microsoft's "Run" time library.
> >
> >That is not something you need to see, want to see, or can help with.
>
> The separation is not always that clear. For example, the discussion
> of issue 130 might benefit from "a first-hand view into hell",
Maybe I am overly cautious, but you remember what drove me away from
msysGit? Exactly, people, and issues, took out all the fun.
Let's not inflict upon git@vger what they did not deserve to suffer.
And if the separation is not always that clear, why not discuss those
things on msysGit first, and then come to git@vger with our minds (and
possibly our patches) made up?
> Another example is the discussion about GIT_EXEC_PATH, see
>
> http://thread.gmane.org/gmane.comp.version-control.msysgit/2633
This is a particularly good example that does not matter for Linux,
MacOSX, Solaris or the BSDs (Git's principal platforms!) at all.
And once this patch hits git@vger, it is still visible to other platforms.
> A last example is the crash of gitk that was observed on Windows and is
> now buried in the msysGit issue tracker, although I am pretty sure that
> is it not windows-specific, see
>
> http://code.google.com/p/msysgit/issues/detail?id=125
So? If it did not hit other platforms, it is the duty of that guy to find
out what it is. And if it _does_ turn out to be a Windows-specific bug,
which might very well be the case, we do not need to add to the volume of
git@vger.
> >Likewise, I think it has nothing to do with the git@vger list when we
> >add work-arounds until some better solution is found, and then discuss
> >whether the workaround is still needed.
> >
> >I cannot help to see the benefit, at least.
> >
> >Once things are sorted out, I agree, it has to be sent to the git list.
> >
> >Before that, however, allow us to work on another list.
>
> Personally, I'd find it easier to work on a single list.
Sure the benefit is undisputed.
Now let's look at the downsides: we take away time, and possibly fun, from
many more people than one or two persons.
It's like spam. Asking somebody to "just hit the delete button" stops
being funny very quickly.
> MinGW support is mature enough and workarounds should now be avoid. If
> we tested git during the official release cycle, we would have
> sufficient time to find and solve problems on Windows and prepare
> patches that have sufficient quality to be discuss on git@vger.
I am not so sure.
Your experience should match mine, that the patches coming in through
msysGit are of a substantial lower quality than what we are used to on
git@vger.
If you want to force those patches unfiltered onto the readers of
git@vger, it would only be fair that you have to clean the readers' latest
lunch out of their keyboards.
Ciao,
Dscho "who has a fata morgana of windmills"
^ permalink raw reply
* Re: [StGIT] Failure to install on RHELWS4
From: Catalin Marinas @ 2008-07-11 21:35 UTC (permalink / raw)
To: Miklos Vajna
Cc: Thomas Rast, Petr Baudis, Git Mailing List, Karl Hasselström
In-Reply-To: <20080711200735.GK10347@genesis.frugalware.org>
2008/7/11 Miklos Vajna <vmiklos@frugalware.org>:
> On Fri, Jul 11, 2008 at 09:26:29PM +0200, Thomas Rast <trast@student.ethz.ch> wrote:
>> > pyver = '.'.join(str(n) for n in sys.version_info)
>> > ^
>> [...]
>> > Python version is 2.3.4
>>
>> That is indeed too old. Generator expressions like the above were
>> introduced in 2.4:
>>
>> http://www.python.org/dev/peps/pep-0289/
>
> So obviously it's a bad idea to use generators for such a version check.
Yes, I agree.
> Also, setup.py would try to import stgit.run before the version check.
>
> I'm sending two patches, which restore the wished "Python version 2.4 or
> newer required. Found 2.2.1.final.0" error message.
Thanks.
--
Catalin
^ permalink raw reply
* [PATCH] git-rebase.sh: Display error output from git-checkout when detaching HEAD fails.
From: Robert Shearman @ 2008-07-11 21:26 UTC (permalink / raw)
To: git; +Cc: Robert Shearman
The "git checkout" command executed could fail if, for example, upstream contains a file that would overrwrite a local, untracked file. The output redirection didn't work as stderr was redirected to /dev/null, as was stdout. This appears to be not what was intended so the order of redirections is fixed so that stderr is redirected to stdout instead.
---
git-rebase.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase.sh b/git-rebase.sh
index e2d85ee..0da2210 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -376,7 +376,7 @@ fi
# Detach HEAD and reset the tree
echo "First, rewinding head to replay your work on top of it..."
-git checkout "$onto^0" >/dev/null 2>&1 ||
+git checkout "$onto^0" 2>&1 >/dev/null ||
die "could not detach HEAD"
# git reset --hard "$onto^0"
--
1.5.6.2.225.g4596.dirty
^ permalink raw reply related
* Re: [GitStats] Bling bling or some statistics on the git.git repository
From: Johannes Schindelin @ 2008-07-11 21:22 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Git Mailinglist, David Symonds
In-Reply-To: <bd6139dc0807111404y1d3dd48ao6d2903da4cd1aa56@mail.gmail.com>
Hi,
On Fri, 11 Jul 2008, Sverre Rabbelier wrote:
> I temporarily modified the code to output %04d instead of %4d so that I
> could do the following:
>
> $ stats.py author -a > full_activity_sortable.txt
You might be delighted to read up on the "-n" switch to sort(1).
> A few highlights from the sorted file:
>
> $ cat full_activity_sortable.txt | sort | tail -n 20
More intuitive would have been "sort -r | head -n 20", I guess.
> 0170: 2721+ 1060- = refs.c
I guess that 170 is the total number of commit touching that file, the "+"
and "-" numbers the changes respectively?
I think quite a lot of our changes do code moves; this should be accounted
for differently.
> 0172: 4369+ 2004- = builtin-pack-objects.c
> 0177: 345+ 233- = GIT-VERSION-GEN
> 0178: 2855+ 2121- = commit.c
> 0178: 4779+ 2227- = fast-import.c
> 0179: 2677+ 1400- = read-cache.c
> 0185: 5661+ 2056- = builtin-apply.c
> 0186: 3269+ 1255- = revision.c
> 0213: 1884+ 460- = Documentation/config.txt
> 0232: 2257+ 1621- = Documentation/git.txt
> 0236: 3990+ 1991- = contrib/fast-import/git-p4
> 0281: 2753+ 2220- = git.c
> 0333: 10259+ 7150- = git-gui.sh
> 0338: 11337+ 6187- = git-svn.perl
> 0338: 5755+ 3159- = sha1_file.c
> 0397: 10230+ 9599- = diff.c
> 0412: 23248+ 20257- = gitk
> 0432: 10580+ 4502- = gitweb/gitweb.perl
> 0490: 1412+ 619- = cache.h
> 0977: 4703+ 2705- = Makefile
>
> $ cat Makefile | wc -l
> 1482
>
> For some reason you people can't seem to make up your mind about a
> file that's not even 1500 lines in size ;).
Heh. We might need to change it once or twice, in the future.
> A note is in order here, this data was mined with "git log --num-stat"
> so things like moving files and copying files are not accounted for.
In my opinion it would be even more interesting to see code moves (i.e.
not whole files). For example, we moved some stuff from builtins into the
library. The real change here is not in the lines added and deleted.
> I thought about using git-blame to gather this info before, but it is
> not the right tool for the job. If anyone else has any idea's on what
> would be better please let me know and I'll happily dig into it :).
I think that you need to analyze the diff directly. One possible (quick
'n dirty) way would be to cut out long consecutive "+" parts of the hunks,
replace the "-" by "+", and use "git diff --no-index" to do the hard part
of searching for that code in the "-" part of the original diff.
If that turns out to be useful, we can still think about a proper API
using xdiff.
Just an idea,
Dscho
^ permalink raw reply
* Re: Should we discuss Windows-related changes on git@vger.kernel.org?
From: Steffen Prohaska @ 2008-07-11 21:10 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Johannes Sixt, Junio C Hamano, msysGit,
Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807112037220.8950@racer>
On Jul 11, 2008, at 9:40 PM, Johannes Schindelin wrote:
> On Fri, 11 Jul 2008, Linus Torvalds wrote:
>
>> - It may well be good to explain to the _real_ git people (eg me)
>> what
>> the problems in Windows land are, so that we get a first-hand view
>> into hell, and can maybe take it into account when we make changes
>> for other things.
>
> Wow. I did not think that you were a masochist.
>
>> IOW, I think that since 1.6.0 is supposed to have native support for
>> windows, we should have patches discussed on the regular git list.
>> The
>> ghetto that is windows can be useful for _user_ discussions, where
>> a lot
>> of the core git people simply cannot help. But having development
>> discussions there is bad, I think.
>
> We do have development discussions there that do not belong to
> git@vger.
> For example, when Hannes reimplemented the utterly broken spawn()
> implementation of Microsoft's "Run" time library.
>
> That is not something you need to see, want to see, or can help with.
The separation is not always that clear. For example, the discussion
of issue 130 might benefit from "a first-hand view into hell", see
http://thread.gmane.org/gmane.comp.version-control.msysgit/2653/focus=2682
Another example is the discussion about GIT_EXEC_PATH, see
http://thread.gmane.org/gmane.comp.version-control.msysgit/2633
It might be triggered by msysGit's need to freely move a git
installation
in the filesystem. The resulting feature might however be interesting
on
other platforms, too.
A last example is the crash of gitk that was observed on Windows and is
now buried in the msysGit issue tracker, although I am pretty sure that
is it not windows-specific, see
http://code.google.com/p/msysgit/issues/detail?id=125
> Likewise, I think it has nothing to do with the git@vger list when
> we add
> work-arounds until some better solution is found, and then discuss
> whether
> the workaround is still needed.
>
> I cannot help to see the benefit, at least.
>
> Once things are sorted out, I agree, it has to be sent to the git
> list.
>
> Before that, however, allow us to work on another list.
Personally, I'd find it easier to work on a single list. MinGW support
is mature enough and workarounds should now be avoid. If we tested git
during the official release cycle, we would have sufficient time to find
and solve problems on Windows and prepare patches that have sufficient
quality to be discuss on git@vger.
Steffen
^ permalink raw reply
* [GitStats] Bling bling or some statistics on the git.git repository
From: Sverre Rabbelier @ 2008-07-11 21:04 UTC (permalink / raw)
To: Git Mailinglist; +Cc: David Symonds
In-Reply-To: <bd6139dc0807090621n308b0159n92d946c165d3a5dd@mail.gmail.com>
[I sent this mail earlier, but I think vger rejected it due to the
size of the attachments, I have uploaded them instead now, they can be
found at:
http://alturin.googlepages.com/activity_per_author.txt
http://alturin.googlepages.com/full_activity.txt ]
Heya,
Today I sat down and finished the activity aggregation code. Now it is
possible to generate the attached files with the following commands:
$ stats.py author -e --id=an > activity_per_author.txt
$ stats.py author -a > full_activity.txt
The first one calculates the activity of all developers on a per-file
basis and dumps it into the file. The "--id=an" switch sets the
grouping field to "%an" (see man git-log), since the default (%ae) is
not that helpful for git.git (I don't know people by their e-mail, I
know them by their name). This was already possible (with "author
-d"), but before one had to pick a specific developer, now it will
show for _all_ developers.This is interesting stuff, although for a
huge project like git it's a bit much to take in. What is probably
more interesting is the second command, it shows how much change a
file has had in it's existence.
I temporarily modified the code to output %04d instead of %4d so that
I could do the following:
$ stats.py author -a > full_activity_sortable.txt
A few highlights from the sorted file:
$ cat full_activity_sortable.txt | sort | tail -n 20
0170: 2721+ 1060- = refs.c
0172: 4369+ 2004- = builtin-pack-objects.c
0177: 345+ 233- = GIT-VERSION-GEN
0178: 2855+ 2121- = commit.c
0178: 4779+ 2227- = fast-import.c
0179: 2677+ 1400- = read-cache.c
0185: 5661+ 2056- = builtin-apply.c
0186: 3269+ 1255- = revision.c
0213: 1884+ 460- = Documentation/config.txt
0232: 2257+ 1621- = Documentation/git.txt
0236: 3990+ 1991- = contrib/fast-import/git-p4
0281: 2753+ 2220- = git.c
0333: 10259+ 7150- = git-gui.sh
0338: 11337+ 6187- = git-svn.perl
0338: 5755+ 3159- = sha1_file.c
0397: 10230+ 9599- = diff.c
0412: 23248+ 20257- = gitk
0432: 10580+ 4502- = gitweb/gitweb.perl
0490: 1412+ 619- = cache.h
0977: 4703+ 2705- = Makefile
$ cat Makefile | wc -l
1482
For some reason you people can't seem to make up your mind about a
file that's not even 1500 lines in size ;). With almost a thousand
edits so far, it's been edited so many times it could've been written
from scratch three times (except that the amount of lines deleted
doesn't match). Also interesting to note is that the "external" files
such as gitweb, gitk, git-gui and git-svn make up the bulk of all
changes. The two contenders from the native git camp are diff.c and
sha1_file.c which both have a lot of LOC. This information is
interesting for GitStats as it might help determine which files have
had a lot of change, and which files are not touched a lot.
A note is in order here, this data was mined with "git log --num-stat"
so things like moving files and copying files are not accounted for. I
thought about using git-blame to gather this info before, but it is
not the right tool for the job. If anyone else has any idea's on what
would be better please let me know and I'll happily dig into it :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: Install GIT?
From: Petr Baudis @ 2008-07-11 21:00 UTC (permalink / raw)
To: mike zheng; +Cc: git
In-Reply-To: <5c9cd53b0807111355u7a346dafne6a3b7bd75d5100e@mail.gmail.com>
Hi,
On Fri, Jul 11, 2008 at 04:55:12PM -0400, mike zheng wrote:
> is there any document on how to compile and install git? Which package
> shall I download from http://www.kernel.org/pub/software/scm/git/?
get the latest version. ;-) That is,
http://www.kernel.org/pub/software/scm/git/git-1.5.6.2.tar.bz2
right now.
> What is the steps to compile each of them?
It is described in the INSTALL file at the project root:
http://repo.or.cz/w/git.git?a=blob;f=INSTALL
--
Petr "Pasky" Baudis
The last good thing written in C++ was the Pachelbel Canon. -- J. Olson
^ permalink raw reply
* Install GIT?
From: mike zheng @ 2008-07-11 20:55 UTC (permalink / raw)
To: git
hello,
is there any document on how to compile and install git? Which package
shall I download from http://www.kernel.org/pub/software/scm/git/?
What is the steps to compile each of them?
thanks in advance,
mike
^ permalink raw reply
* Re: [PATCH] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable
From: Johannes Schindelin @ 2008-07-11 20:40 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, git, Dmitry Kakurin
In-Reply-To: <920CBA3F-779D-4861-B447-135690B4E8BD@zib.de>
Hi,
On Fri, 11 Jul 2008, Steffen Prohaska wrote:
> On Jul 11, 2008, at 8:42 PM, Johannes Schindelin wrote:
>
> >On Fri, 11 Jul 2008, Steffen Prohaska wrote:
> >
> > >From: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
> > >
> > >Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
> > >Signed-off-by: Steffen Prohaska <prohaska@zib.de>
> > >---
> > >convert.c | 4 ++++
> > >1 files changed, 4 insertions(+), 0 deletions(-)
> > >
> > >diff --git a/convert.c b/convert.c
> > >index 352b69d..78efed8 100644
> > >--- a/convert.c
> > >+++ b/convert.c
> > >@@ -61,6 +61,10 @@ static void gather_stats(const char *buf, unsigned long
> > >size, struct text_stat *
> > > else
> > > stats->printable++;
> > > }
> > >+
> > >+ /* If file ends with EOF then don't count this EOF as non-printable.
> > >*/
> > >+ if (size >= 1 && buf[size-1] == '\032')
> > >+ stats->nonprintable--;
> >
> >This is one of the things that are very specific to Windows and should not
> >affect other people.
>
> Does this mean you are opposed to this change?
Hrm. Thinking about it again, this _could_ help Unix people who
collaborate with DOS people.
OTOH it will just hide the fact that text files were committed that
contain silly characters.
On the third hand, this code path affects only people who set autocrlf.
Well, I guess they asked for it, kind of.
Ciao,
Dscho
^ permalink raw reply
* Re: feature request: git-log should accept sth like v2.6.26-rc8-227
From: Johannes Schindelin @ 2008-07-11 20:35 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Toralf Förster, git
In-Reply-To: <alpine.DEB.1.00.0807112041470.8950@racer>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1833 bytes --]
Hi,
On Fri, 11 Jul 2008, Johannes Schindelin wrote:
> On Fri, 11 Jul 2008, Dmitry Potapov wrote:
>
> > On Fri, Jul 11, 2008 at 04:58:40PM +0200, Toralf Förster wrote:
> > >
> > > $> git-log v2.6.26-rc9.. --pretty=short | grep "^commit" | cut -f2 -d' ' | xargs -n 1 git describe | grep '\-56\-'
> >
> > The fastest way to do the same would be:
> >
> > git rev-list v2.6.26-rc9.. | xargs git describe | grep '\-56\-'
>
> You forgot the "--all" option to rev-list.
>
> And I doubt it would be the "fastest" way, in terms of execution speed.
>
> Also, it leaves out this case:
>
> rc9 - A - B - C - D - F
> \ /
> ----- E -----
>
> F would be "rc9-5", but also "rc9-2".
>
> Oh, and this would leave out reflogs, too.
>
> Can we please let this concept die now?
Heh, just as an intellectual exercise, I could not resist trying to brush
up my l33t py7h0n sk1llz (and I am sure somebody will teach me something
useful again):
-- snipsnap --
#!/usr/bin/python
import os
import sys
if len(sys.argv) != 2:
print 'Usage:', sys.argv[0], '<pseudo-describe>'
# split argument
dash = sys.argv[1].rindex('-')
tag = sys.argv[1][0:dash]
generation = int(sys.argv[1][dash + 1:])
# get sha1 of given tag's commit
pipe = os.popen('git rev-parse ' + tag + '^{commit}')
sha1 = pipe.readlines()[0].strip()
pipe.close()
# 'number' will contain (positive) distance to given commit
number = dict()
number[sha1] = set()
number[sha1].add(0)
pipe = os.popen('git rev-list ^' + sha1 + ' --all --parents')
rev_list = pipe.readlines()
pipe.close()
rev_list.reverse()
for line in rev_list:
list = line.strip().split(' ')
number[list[0]] = set()
for parent in list[1:]:
if parent in number:
for n in number[parent]:
number[list[0]].add(n + 1)
for n in number[list[0]]:
if n == generation:
print list[0]
^ permalink raw reply
* Re: [PATCH] Fixed text file auto-detection: treat EOF character 032 at the end of file as printable
From: Steffen Prohaska @ 2008-07-11 20:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, Dmitry Kakurin
In-Reply-To: <alpine.DEB.1.00.0807111940420.8950@racer>
On Jul 11, 2008, at 8:42 PM, Johannes Schindelin wrote:
> On Fri, 11 Jul 2008, Steffen Prohaska wrote:
>
>> From: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
>>
>> Signed-off-by: Dmitry Kakurin <Dmitry.Kakurin@gmail.com>
>> Signed-off-by: Steffen Prohaska <prohaska@zib.de>
>> ---
>> convert.c | 4 ++++
>> 1 files changed, 4 insertions(+), 0 deletions(-)
>>
>> diff --git a/convert.c b/convert.c
>> index 352b69d..78efed8 100644
>> --- a/convert.c
>> +++ b/convert.c
>> @@ -61,6 +61,10 @@ static void gather_stats(const char *buf,
>> unsigned long size, struct text_stat *
>> else
>> stats->printable++;
>> }
>> +
>> + /* If file ends with EOF then don't count this EOF as non-
>> printable. */
>> + if (size >= 1 && buf[size-1] == '\032')
>> + stats->nonprintable--;
>
> This is one of the things that are very specific to Windows and
> should not
> affect other people.
Does this mean you are opposed to this change?
Junio thinks that "the intention of this change is good" [1]. Hence,
I cleaned up the style and re-send the patch.
[1] http://article.gmane.org/gmane.comp.version-control.git/87122
Steffen
^ permalink raw reply
* [PATCH] setup.py: don't try to import stgit.run before the python version check
From: Miklos Vajna @ 2008-07-11 20:09 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Thomas Rast, Petr Baudis, Git Mailing List
In-Reply-To: <20080711200735.GK10347@genesis.frugalware.org>
stgit.run would import datetime, which is not available in older python
versions. import it just after the version check passed.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
setup.py | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/setup.py b/setup.py
index 44cc6ea..a685cf6 100755
--- a/setup.py
+++ b/setup.py
@@ -4,7 +4,6 @@ import sys, glob, os
from distutils.core import setup
from stgit import version
-from stgit.run import Run
def __version_to_list(version):
"""Convert a version string to a list of numbers or strings
@@ -68,6 +67,8 @@ if sys.argv[1] in ['install', 'build']:
__check_python_version()
__check_git_version()
+from stgit.run import Run
+
# ensure readable template files
old_mask = os.umask(0022)
--
1.5.6.2.450.g8d367.dirty
^ permalink raw reply related
* [PATCH] setup.py: fix error message when running with python-2.3
From: Miklos Vajna @ 2008-07-11 20:09 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Thomas Rast, Petr Baudis, Git Mailing List
In-Reply-To: <20080711200735.GK10347@genesis.frugalware.org>
When setup.py tries to check the python version, the check actually
won't give a usable error message but it'll raise a SyntaxError. Fix
this by not using generator expressions.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
setup.py | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/setup.py b/setup.py
index 8d8f7a8..44cc6ea 100755
--- a/setup.py
+++ b/setup.py
@@ -28,7 +28,7 @@ def __check_min_version(min_ver, ver):
def __check_python_version():
"""Check the minimum Python version
"""
- pyver = '.'.join(str(n) for n in sys.version_info)
+ pyver = '.'.join(map(lambda x: str(x), sys.version_info))
if not __check_min_version(version.python_min_ver, pyver):
print >> sys.stderr, 'Python version %s or newer required. Found %s' \
% (version.python_min_ver, pyver)
--
1.5.6.2.450.g8d367.dirty
^ permalink raw reply related
* Re: [StGIT] Failure to install on RHELWS4
From: Miklos Vajna @ 2008-07-11 20:07 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Thomas Rast, Petr Baudis, Git Mailing List
In-Reply-To: <200807112126.39729.trast@student.ethz.ch>
[-- Attachment #1: Type: text/plain, Size: 679 bytes --]
On Fri, Jul 11, 2008 at 09:26:29PM +0200, Thomas Rast <trast@student.ethz.ch> wrote:
> > pyver = '.'.join(str(n) for n in sys.version_info)
> > ^
> [...]
> > Python version is 2.3.4
>
> That is indeed too old. Generator expressions like the above were
> introduced in 2.4:
>
> http://www.python.org/dev/peps/pep-0289/
So obviously it's a bad idea to use generators for such a version check.
Also, setup.py would try to import stgit.run before the version check.
I'm sending two patches, which restore the wished "Python version 2.4 or
newer required. Found 2.2.1.final.0" error message.
(Tested with Python 2.2.1.)
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: feature request: git-log should accept sth like v2.6.26-rc8-227
From: Johannes Schindelin @ 2008-07-11 19:57 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Toralf Förster, git
In-Reply-To: <20080711192902.GD1721@dpotapov.dyndns.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 706 bytes --]
Hi,
On Fri, 11 Jul 2008, Dmitry Potapov wrote:
> On Fri, Jul 11, 2008 at 04:58:40PM +0200, Toralf Förster wrote:
> >
> > $> git-log v2.6.26-rc9.. --pretty=short | grep "^commit" | cut -f2 -d' ' | xargs -n 1 git describe | grep '\-56\-'
>
> The fastest way to do the same would be:
>
> git rev-list v2.6.26-rc9.. | xargs git describe | grep '\-56\-'
You forgot the "--all" option to rev-list.
And I doubt it would be the "fastest" way, in terms of execution speed.
Also, it leaves out this case:
rc9 - A - B - C - D - F
\ /
----- E -----
F would be "rc9-5", but also "rc9-2".
Oh, and this would leave out reflogs, too.
Can we please let this concept die now?
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Added --export option to git-send-email.
From: Eduard - Gabriel Munteanu @ 2008-07-11 19:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: ryan, git
In-Reply-To: <7vskugkimt.fsf@gitster.siamese.dyndns.org>
On Fri, 11 Jul 2008 00:03:06 -0700
Junio C Hamano <gitster@pobox.com> wrote:
> Eduard - Gabriel Munteanu <eduard.munteanu@linux360.ro> writes:
>
> > This option allows the user to process patches with git-send-email
> > and then import them into an email client, without having to send
> > them directly. The output format is mbox.
>
> Input format is also mbox, so an obvious question is "why?"
Hi,
git-send-email has a lot more mail processing power than
git-format-patch. For example, there is no way to fill in "To:" with
git-format-patch.
I use this because I want to send the emails with my mail client
(Claws-Mail), not directly. This allows me to use git-send-email to
process patches instead of kludging the headers with something like
formail.
Eduard
^ permalink raw reply
* Re: Should we discuss Windows-related changes on git@vger.kernel.org?
From: Johannes Schindelin @ 2008-07-11 19:40 UTC (permalink / raw)
To: Linus Torvalds
Cc: Steffen Prohaska, Johannes Sixt, Junio C Hamano, msysGit,
Git Mailing List
In-Reply-To: <alpine.LFD.1.10.0807111159560.2936@woody.linux-foundation.org>
Hi,
On Fri, 11 Jul 2008, Linus Torvalds wrote:
> - It may well be good to explain to the _real_ git people (eg me) what
> the problems in Windows land are, so that we get a first-hand view
> into hell, and can maybe take it into account when we make changes
> for other things.
Wow. I did not think that you were a masochist.
> IOW, I think that since 1.6.0 is supposed to have native support for
> windows, we should have patches discussed on the regular git list. The
> ghetto that is windows can be useful for _user_ discussions, where a lot
> of the core git people simply cannot help. But having development
> discussions there is bad, I think.
We do have development discussions there that do not belong to git@vger.
For example, when Hannes reimplemented the utterly broken spawn()
implementation of Microsoft's "Run" time library.
That is not something you need to see, want to see, or can help with.
Likewise, I think it has nothing to do with the git@vger list when we add
work-arounds until some better solution is found, and then discuss whether
the workaround is still needed.
I cannot help to see the benefit, at least.
Once things are sorted out, I agree, it has to be sent to the git list.
Before that, however, allow us to work on another list.
Ciao,
Dscho
^ permalink raw reply
* Re: feature request: git-log should accept sth like v2.6.26-rc8-227
From: Dmitry Potapov @ 2008-07-11 19:29 UTC (permalink / raw)
To: Toralf Förster; +Cc: Johannes Schindelin, git
In-Reply-To: <200807111658.40626.toralf.foerster@gmx.de>
On Fri, Jul 11, 2008 at 04:58:40PM +0200, Toralf Förster wrote:
>
> $> git-log v2.6.26-rc9.. --pretty=short | grep "^commit" | cut -f2 -d' ' | xargs -n 1 git describe | grep '\-56\-'
The fastest way to do the same would be:
git rev-list v2.6.26-rc9.. | xargs git describe | grep '\-56\-'
Dmitry
^ permalink raw reply
* Re: [StGIT] Failure to install on RHELWS4
From: Thomas Rast @ 2008-07-11 19:26 UTC (permalink / raw)
To: Petr Baudis; +Cc: Git Mailing List
In-Reply-To: <20080711170356.GF32184@machine.or.cz>
[-- Attachment #1: Type: text/plain, Size: 348 bytes --]
Petr Baudis wrote:
>
> pyver = '.'.join(str(n) for n in sys.version_info)
> ^
[...]
> Python version is 2.3.4
That is indeed too old. Generator expressions like the above were
introduced in 2.4:
http://www.python.org/dev/peps/pep-0289/
- Thomas
--
Thomas Rast
trast@student.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Should we discuss Windows-related changes on git@vger.kernel.org?
From: Linus Torvalds @ 2008-07-11 19:04 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Steffen Prohaska, Johannes Sixt, Junio C Hamano, msysGit,
Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807111930160.8950@racer>
On Fri, 11 Jul 2008, Johannes Schindelin wrote:
>
> Which very much includes brushing up the patches in 4msysgit, which are
> invariably of lower quality than git.git's, because we lack a brilliant
> maintainer like Junio.
Umm. The other side of the coin is:
- a lot of people with good taste won't _be_ on the windows lists,
because there is likely a high correlation with "good taste in
development" and "try to avoid using windows"
- a lot of Junio's maintenance is likely helped by the fact that (a) he
sees the features being discussed and the reason for them and (b) the
patches have in general seen comments from other people.
- It may well be good to explain to the _real_ git people (eg me) what
the problems in Windows land are, so that we get a first-hand view into
hell, and can maybe take it into account when we make changes for other
things.
IOW, I think that since 1.6.0 is supposed to have native support for
windows, we should have patches discussed on the regular git list. The
ghetto that is windows can be useful for _user_ discussions, where a lot
of the core git people simply cannot help. But having development
discussions there is bad, I think.
Linus
^ permalink raw reply
* Re: how to undo a git merge?
From: Sverre Rabbelier @ 2008-07-11 18:55 UTC (permalink / raw)
To: ff; +Cc: Miklos Vajna, git
In-Reply-To: <fa7d16350807111146m18b0ca9q6902c2167bfd3512@mail.gmail.com>
On Fri, Jul 11, 2008 at 8:46 PM, ff <ff@member.org> wrote:
>> For example, if you were on branch 'master' and you merged 'foo' to
>> master using 'git merge foo', and you want to revert that merge then you
>> need '-m 1'.
>
> In your example, how and why you can determine that the number 1
> represents the "foo" branch? Would "-m 2" represent the master branch?
> In your example is there any other choice for the "-m" number to use?
When you perform a merge on branch A, like so:
git checkout A # first switch to the branch you want the merge to be on
git merge B # now do the actual merge with the branch you want to merge with
The resulting merge commit will have the head of A as it's first
parent, and the head of B as it's second parent. With the -m switch
you can specify which parent you want to follow. If for example, you
have a three-way merge, like so ..:
git checkout A
git merge B C
.. the resulting merge commit would have A as it's first, B as it's
second and C as it's third parent. If you want to revert to the state
of C then you specify -m 3, so that the third parent is chosen. If you
performed the merge on the branch that you want to revert to, you
always specify -m 1. If you did this ..:
git checkout B
git merge A
.. and then you want to restore the state of branch A, you use '-m 2'.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: how to undo a git merge?
From: Miklos Vajna @ 2008-07-11 18:53 UTC (permalink / raw)
To: ff; +Cc: git
In-Reply-To: <fa7d16350807111146m18b0ca9q6902c2167bfd3512@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 619 bytes --]
On Fri, Jul 11, 2008 at 02:46:15PM -0400, ff <ff@member.org> wrote:
> ooops... yes... I'm scared of the reply-all button. :)
Also please don't top-post, thanks. ;-)
> In your example, how and why you can determine that the number 1
> represents the "foo" branch? Would "-m 2" represent the master branch?
> In your example is there any other choice for the "-m" number to use?
If the merge has two parents, then the first one is the actual branch
and the second is the 'other' branch.
So if 'master' is checked out, you did a 'git merge foo', and you want
to do a revert, '1' stands for 'master' and '2' for 'foo'.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git cherry-pick before archive
From: Johannes Schindelin @ 2008-07-11 18:53 UTC (permalink / raw)
To: Denis Bueno; +Cc: Miklos Vajna, Git Mailing List
In-Reply-To: <6dbd4d000807111149s4fb661cak9fac152864260901@mail.gmail.com>
Hi,
On Fri, 11 Jul 2008, Denis Bueno wrote:
> On Fri, Jul 11, 2008 at 14:46, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > BTW in your case, I would suggest this:
> >
> > INDEX_FILE=.git/bla git read-tree HEAD &&
> > INDEX_FILE=.git/bla git apply --cached patchfile &&
> > INDEX_FILE=.git/bla git archive [...] &&
> > rm .git/bla
> >
> > IOW: Just use a temporary index for your work.
>
> What is the rationale? So I can relieve the assumption that the index
> is clean?
Not completely.
It will just leave the current index alone, ignoring the changes within
it. It will also avoid having to update the index several times.
IMO it is just the thing you should do here: you do not want to stage
anything for commit, so keep .git/index as-is, and use a temporary staging
area instead.
It also avoids the need to "undo" things that might not be easily undone:
if your patch contains stuff that was partly in the index, but
uncommitted, neither "git reset" nor "git revert -n" will do what you
want.
Ciao,
Dscho
^ 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