* 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
* Re: git cherry-pick before archive
From: Denis Bueno @ 2008-07-11 18:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Miklos Vajna, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807111944000.8950@racer>
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?
--
Denis
^ permalink raw reply
* Re: git cherry-pick before archive
From: Johannes Schindelin @ 2008-07-11 18:46 UTC (permalink / raw)
To: Denis Bueno; +Cc: Miklos Vajna, Git Mailing List
In-Reply-To: <6dbd4d000807111128l4721113dh3713bc7abd3d837e@mail.gmail.com>
Hi,
On Fri, 11 Jul 2008, Denis Bueno wrote:
> On Fri, Jul 11, 2008 at 14:25, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> > Anyway, back to Denis' question: I could imagine (haven't tested,
> > thought), that "git revert -n <the-same-commit>" would undo the "git
> > cherry-pick -n".
>
> So I need to be able to maintain the patch that is applied to the tree
> before archiving, so instead of a commit ID, I'm now using a patch
> file, and the sequence of actions is like so:
>
> $ <assume index is clean>
> $ git apply --cached patchfile || exit 1
> $ git archive --format=tar --prefix=pfx/ $(git write-tree) \
> | gzip > prj.tgz
> $ git reset
>
> This way I don't even need to reverse-apply the patch, because I never
> touch the working copy. Of course, this can't be done in this way in
> any other revision control system, because they don't have an index.
Well, they have. They just do not expose it.
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.
Ciao,
Dscho
^ permalink raw reply
* Re: how to undo a git merge?
From: ff @ 2008-07-11 18:46 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20080711181413.GI10347@genesis.frugalware.org>
> [ Did you reply off-list intentionally? ]
ooops... yes... I'm scared of the reply-all button. :)
> 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'.
Ok, so... sorry for not getting it completely, even after reading the info.
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?
-- ff
On Fri, Jul 11, 2008 at 2:14 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
> [ Did you reply off-list intentionally? ]
>
> On Fri, Jul 11, 2008 at 02:07:44PM -0400, ff <ff@member.org> wrote:
>> thank you.
>>
>> I did see the -m option in the revert man page. It talks about
>> "parent" and I did
>> not understand what that is. Is parent the commit id of the merge commit?
>>
>> Thanks again!
>
> http://www.kernel.org/pub/software/scm/git/docs/gitglossary.html#def_parent
>
> A merge commit has two parents, but obviously only one of the was the
> HEAD commit before the merge. So when you revert a merge, you need to
> specify which which parent's tree should be the tree of the new HEAD.
>
> 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'.
>
^ 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 18:42 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, git, Dmitry Kakurin
In-Reply-To: <1215794896-31354-1-git-send-email-prohaska@zib.de>
Hi,
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.
Ciao,
Dscho
P.S.: this is one of the examples why I would like to discuss things that
are Windows-only on the msysGit list, until we have a consensus there. We
have a few Git experts there, you and Hannes in particular, which cover
that side, but also some Windows experts such as Peter and Marius, and we
should not need to have that discussion on a list where people are not
expected to care about Windows _at all_.
^ permalink raw reply
* Re: Should we discuss Windows-related changes on git@vger.kernel.org?
From: Johannes Schindelin @ 2008-07-11 18:36 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Sixt, Junio C Hamano, msysGit, Git Mailing List
In-Reply-To: <A065AF71-5685-423A-9F87-5349ADC6C9C9@zib.de>
Hi,
On Fri, 11 Jul 2008, Steffen Prohaska wrote:
> On Jul 11, 2008, at 5:57 PM, Johannes Schindelin wrote:
>
> >On Fri, 11 Jul 2008, Steffen Prohaska wrote:
> >
> > >On Jul 11, 2008, at 1:56 PM, Johannes Schindelin wrote:
> > >
> > > >On Fri, 11 Jul 2008, Steffen Prohaska wrote:
> > > >
> > > > >I decided to stop queuing changes in 4msysgit. Instead I'd like
> > > > >to bring the diff between Junio's and 4msysgit's master to zero.
> > > > >This seems to be achievable after Junio merged Hannes' MinGW
> > > > >changes.
> > > > >
> > > > >I think all Windows-related changes to the git code base could be
> > > > >discussed directly on the main git list and the msysgit list
> > > > >would be reserved for the MinGW/MSYS runtime environment and the
> > > > >installer.
> > > >
> > > >I disagree. Judging from the mails I read on the git list, Junio
> > > >gets really swamped by patches these days (what with our very
> > > >productive GSoC students).
> > >
> > >Sending the patches to the git list does not necessarily mean that
> > >they are directly addressed to Junio. We discuss JGIT, EGIT, gitk,
> > >and git gui patches on the list too. AFAIK, none of them are applied
> > >by Junio directly but by the respective maintainers. We could handle
> > >Windows-related patches similarly.
> >
> >Then what is the msysGit list about?
>
> I think the msysGit list could be useful for:
>
> - Everything that is in the msysgit repo, i.e. the MinGW/MSYS
> runtime environment and the installers.
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.
Come to think of it, we do not have a maintainer at all. Many people can
commit and push into 4msysgit, and I am debating with myself for a long
time already if that was a sensible thing to do. Just think of that C#
desaster.
> >No, I really disagree. Windows support is too large a thing, and
> >partly a too disgusting one to bother the git list.
>
> My understanding is that the mainline of git starts supporting the MinGW
> port with version 1.6.0. The MinGW port is merged to Junio's master, so
> the remaining differences between Junio's master and 4msysgit's master
> should be removed and afterwards new changes should be discussed,
> improved, and applied to Junio's master anyway. This would also allow
> to directly test Junio's next on Windows.
Junio expressed several times that he is uncomfortable that he cannot
easily test Windows support himself.
I strongly doubt that discussing things on git@vger that are not even
half-cooked would help that impression.
Also, there are a lot of people on git@vger who could not care _less_
about Windows.
And there are a few on the list who could not care less about those
Windows users who seem to be content to let others work for them, but
comment at every _possible_ occasion, on what should, and what should not
be done. Let's keep them on the msysGit list, for the benefit of the
saner half of git@vger.
> > > >I really think that we should discuss the patches on the msysGit
> > > >list first, whip them into shape, and then send them off.
> > > >
> > > >Just think of those patches that were sent off, only to realize
> > > >that they were no longer needed. That should not have happened.
> > >
> > >I intentionally sent the patches to show and discuss the differences
> > >between the state of the MinGW port in Junio's master and in
> > >4msysgit. Some of the patches could be reverted in 4msysgit. But, at
> > >least one patch was unrelated to MinGW and is now in master. Some
> > >other patches need more work and are currently improved. I think
> > >this was not a waste of time.
> >
> >IMO we could have discussed first what is the current state on the
> >msysGit list, and I would have commented there already on the patches
> >that I think would no longer be needed.
> >
> >Then the patch would have been sent off, and be in master, too.
> >
> >The difference: it would have been more efficient. Those people who
> >can test if something is still needed on Windows are on the msysGit
> >list.
> >
> >We do not really need to clutter git@vger more than necessary.
>
> But git 1.6 will contain the MinGW port. Shouldn't related patches then
> be discussed on git@vger?
See above. There will be a rudimentary support for MinGW, yes, but that's
for hardcore people like Hannes.
For those who just want to use Git on Windows, there is msysGit. And
for them, we have the msysGit list.
Let's not confuse things, let's not upset git@vger with too many less
clueful users who should rather post to msysgit@googlegroups.com.
Ciao,
Dscho
^ permalink raw reply
* Re: how to undo a git merge?
From: Jakub Narebski @ 2008-07-11 18:36 UTC (permalink / raw)
To: ff; +Cc: git
In-Reply-To: <fa7d16350807111108y3a8a7c3di19598a56dbbcdc15@mail.gmail.com>
ff (?) wrote:
>
> I did see the -m option in the revert man page. It talks about
> "parent" and I did not understand what that is. Is parent the commit
> id of the merge commit?
It is _number_ of parent.
-m parent-number, --mainline parent-number
Usually you cannot revert a merge because you do not know which side
of the merge should be considered the mainline. This option speci-
fies the parent number (starting from 1) of the mainline and allows
revert to reverse the change relative to the specified parent.
Merge commit has more than one parent. What git-revert does, it
creates commit which reverts the changes, as if applying "reversal"
diff, "git diff -R <revision>^<parent-number> <revision>".
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: git cherry-pick before archive
From: Denis Bueno @ 2008-07-11 18:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Miklos Vajna, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0807111924180.8950@racer>
On Fri, Jul 11, 2008 at 14:25, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> Anyway, back to Denis' question: I could imagine (haven't tested,
> thought), that "git revert -n <the-same-commit>" would undo the "git
> cherry-pick -n".
So I need to be able to maintain the patch that is applied to the tree
before archiving, so instead of a commit ID, I'm now using a patch
file, and the sequence of actions is like so:
$ <assume index is clean>
$ git apply --cached patchfile || exit 1
$ git archive --format=tar --prefix=pfx/ $(git write-tree) \
| gzip > prj.tgz
$ git reset
This way I don't even need to reverse-apply the patch, because I never
touch the working copy. Of course, this can't be done in this way in
any other revision control system, because they don't have an index.
--
Denis
^ permalink raw reply
* Re: git cherry-pick before archive
From: Johannes Schindelin @ 2008-07-11 18:25 UTC (permalink / raw)
To: Miklos Vajna; +Cc: Denis Bueno, Git Mailing List
In-Reply-To: <20080711161158.GD10347@genesis.frugalware.org>
Hi,
On Fri, 11 Jul 2008, Miklos Vajna wrote:
> On Fri, Jul 11, 2008 at 12:09:02PM -0400, Denis Bueno <dbueno@gmail.com> wrote:
> > On Fri, Jul 11, 2008 at 11:51, Johannes Schindelin
> > <Johannes.Schindelin@gmx.de> wrote:
> > > $ git cherry-pick -n <bla>
> > > $ git archive --format=tar --prefix=pfx/ $(git write-tree) | gzip > prj.tgz
> > > $ git reset
>
> I guess he wanted to write 'git reset --hard' here ;-)
He did not ;-) "git reset" resets only the index, which is what I wanted.
Anyway, back to Denis' question: I could imagine (haven't tested,
thought), that "git revert -n <the-same-commit>" would undo the "git
cherry-pick -n".
Please test and report back,
Dscho
^ permalink raw reply
* Re: how to undo a git merge?
From: Miklos Vajna @ 2008-07-11 18:14 UTC (permalink / raw)
To: ff; +Cc: git
In-Reply-To: <fa7d16350807111107o40c5cbb5xc06c3c56b16b7499@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 771 bytes --]
[ Did you reply off-list intentionally? ]
On Fri, Jul 11, 2008 at 02:07:44PM -0400, ff <ff@member.org> wrote:
> thank you.
>
> I did see the -m option in the revert man page. It talks about
> "parent" and I did
> not understand what that is. Is parent the commit id of the merge commit?
>
> Thanks again!
http://www.kernel.org/pub/software/scm/git/docs/gitglossary.html#def_parent
A merge commit has two parents, but obviously only one of the was the
HEAD commit before the merge. So when you revert a merge, you need to
specify which which parent's tree should be the tree of the new HEAD.
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'.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ 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