Jonathan Nieder wrote:
Ramkumar Ramachandra wrote:
The short undiplomatic version of that is that our mentors suck (I'm
not pointing fingers, but that's what I infer from failing projects).
Hold on a second. I'm not remembering such a grim outcome with 100%
failure from prior summers of
Junio C Hamano wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
...
I think the real issue is everybody in the GSoC mentor candidate
pool grossly underestimates the scope of suggested projects, does
not encourage students to send early drafts to the public from
On 19/02/13 00:07, Junio C Hamano wrote:
I think you are misreading a suggestion that is somewhat misguided
(yes [ condition another ] does not make sense, but that is
not applicable to test conditon test another); ignore it.
It is fine to write test condition test another and that
Ramkumar Ramachandra artag...@gmail.com writes:
Jonathan Nieder wrote:
Ramkumar Ramachandra wrote:
The short undiplomatic version of that is that our mentors suck (I'm
not pointing fingers, but that's what I infer from failing projects).
Hold on a second. I'm not remembering such a grim
Jeff King wrote:
On Tue, Feb 19, 2013 at 01:15:49AM +0530, Ramkumar Ramachandra wrote:
Take what I'm about to say with a pinch of salt, because I've never mentored.
Mentors often don't provide much technical assistance: students should
just post to the list with queries, or ask on
Blind wrote:
If I understand correctly,
in your scenario the branches with branch.name.pushremote
will be still included in the $git push remote --all?
Yes, this is correct.
Are you considering some way to exclude a branch from push --all
(branch.name.push = always, explicit, never... for
Hi,
I wrote a commit message beginning with a hash (#) character, like this: 'git
commit -m #ifdef '
Everything went okay when committing, but then I tried 'git commit -amend' and
without editing the commit message I was told I had an empty commit message.
Is this a problem with my text
On Mon, Feb 18, 2013 at 07:27:50AM -0500, W. Trevor King wrote:
On Mon, Feb 18, 2013 at 12:56:07AM -0800, Junio C Hamano wrote:
I've taken the following to 'maint'…
Should I rebase v4 onto maint so I don't accidentally collide with any
of the previous patches which have already been merged
On 02/19/2013 10:32 AM, David Wade wrote:
Hi,
I wrote a commit message beginning with a hash (#) character, like
this: 'git commit -m #ifdef '
Everything went okay when committing, but then I tried 'git commit
-amend' and without editing the commit message I was told I had an
empty
On Tue, Feb 19, 2013 at 10:32 AM, David Wade da...@statoil.com wrote:
Hi,
I wrote a commit message beginning with a hash (#) character, like this: 'git
commit -m #ifdef '
Everything went okay when committing, but then I tried 'git commit -amend'
and without editing the commit message
Karsten Blees wrote:
Am 11.02.2013 04:53, schrieb Duy Nguyen:
On Sun, Feb 10, 2013 at 11:58 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
Karsten Blees has done something similar-ish on Windows, and he posted
the results here:
Robert Zeh wrote:
On Sun, Feb 10, 2013 at 9:21 PM, Duy Nguyen pclo...@gmail.com wrote:
On Mon, Feb 11, 2013 at 2:03 AM, Robert Zeh robert.allan@gmail.com
wrote:
On Sat, Feb 9, 2013 at 1:35 PM, Junio C Hamano gits...@pobox.com wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
This
Hi,
This is my first time on this list (and by the way, I'm not subscribed,
so please Cc me to the replies). I have an idea that could be useful to
make rewriting history safer and easier to new users (I'm training some
of them). I thought I could share this idea, but perhaps someone already
Ramkumar Ramachandra artag...@gmail.com writes:
I have this itch where I want to share my remotes config between
machines. In my fork, I should be able to specify where my upstream
sources are, so remotes get set up automatically when I clone.
Note that you need to carefully pick only
From: W. Trevor King wk...@tremily.us
Changes since v3 (v3 numbering):
* 1: user-manual: Use 'remote add' to setup push URLs
- Dropped (graduated into 'maint', e9b4908)
* 2: user-manual: Reorganize the reroll sections, adding 'git rebase -i'
- Added some comments giving example uses of
From: W. Trevor King wk...@tremily.us
Less work and more error checking (e.g. does a merge base exist?).
Add an explicit push before request-pull to satisfy request-pull,
which checks to make sure the references are publically available.
Signed-off-by: W. Trevor King wk...@tremily.us
---
From: W. Trevor King wk...@tremily.us
If you try and update a submodule with a dirty working directory, you
get an error message like:
$ git submodule update
error: Your local changes to the following files would be overwritten by
checkout:
...
Please, commit your changes or stash them
From: W. Trevor King wk...@tremily.us
I think this interface is often more convenient than extended cherry
picking or using 'git format-patch'. In fact, I removed the
cherry-pick section entirely. The entry-level suggestions for
rerolling are now:
1. git commit --amend
2. git format-patch
Mildred Ki'Lya mildred...@mildred.fr writes:
The idea is to basically track automatically (in notes, either in the
notes namespace or in another namespace) which repository/remote
contains a commit. When doing git log, we'd see lines with each
commit, something like:
commit
Thomas Rast wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
I have this itch where I want to share my remotes config between
machines. In my fork, I should be able to specify where my upstream
sources are, so remotes get set up automatically when I clone.
Note that you need to
On Tue, Feb 19, 2013 at 10:38:09AM +0100, Mildred Ki'Lya wrote:
Then, we could have all the history rewriting commands (such as
rebase or pull --rebase) die when rewriting commits that are already
published anywhere. We could make an exception for a --force/-f flag
or configuration option, or
On Tue, Feb 19, 2013 at 11:13:19AM +0100, Thomas Rast wrote:
It's much easier, if a bit slower, to just run
git branch -r --contains $commit
Ah, this would be better than looping in your hook ;).
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more
On Tue, Feb 19, 2013 at 4:25 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Hi,
I have this itch where I want to share my remotes config between
machines. In my fork, I should be able to specify where my upstream
sources are, so remotes get set up automatically when I clone. There
are
Ramkumar Ramachandra artag...@gmail.com writes:
Thomas Rast wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
There are also other things in .git/config that would be nice to
share, like whether to do a --word-diff (why isn't it a configuration
variable yet?)
Because that would break
Nguyễn Thái Ngọc Duy pclouds at gmail.com writes:
I just realized that many of my big repos are still on index v2 while
v4 should reduce its size significantly (3.8M - 2.9M for linux-2.6
and 25M - 14M for webkit, for example). I wanted to propose index v4
as the new default version, because
On Tue, Feb 19, 2013 at 5:45 PM, Thomas Ackermann th.ac...@arcor.de wrote:
Nguyễn Thái Ngọc Duy pclouds at gmail.com writes:
I just realized that many of my big repos are still on index v2 while
v4 should reduce its size significantly (3.8M - 2.9M for linux-2.6
and 25M - 14M for webkit, for
On Tue, Feb 19, 2013 at 4:47 PM, Erik Faye-Lund kusmab...@gmail.com wrote:
On Tue, Feb 19, 2013 at 10:32 AM, David Wade da...@statoil.com wrote:
Hi,
I wrote a commit message beginning with a hash (#) character, like this:
'git commit -m #ifdef '
Everything went okay when committing,
From: W. Trevor King wk...@tremily.us
Descriptions borrowed from templates/hooks--pre-rebase.sample.
Signed-off-by: W. Trevor King wk...@tremily.us
---
I'm not 100% convinced about this, because the git-rebase.sh uses:
$GIT_DIR/hooks/pre-rebase ${1+$@}
I haven't been able to find
2013/2/19 Ramkumar Ramachandra:
No. I don't see why push.default is limiting.
I just want to find a way to exclude a branch (or infact a group of
branches) from $git push --all.
so when I read your thing, I thought for a second that it could be a
possibility... But seems its not the case.
...
Html documents will be installed to root dir (/) no matter what prefix
is set, if run these commands before `make` and `make install-html`:
$ make configure
$ ./configure --prefix=PREFIX
After the installation, all the html documents will copy to rootdir (/),
and:
$ git --html-path
Blind wrote:
2013/2/19 Ramkumar Ramachandra:
No. I don't see why push.default is limiting.
I just want to find a way to exclude a branch (or infact a group of
branches) from $git push --all.
so when I read your thing, I thought for a second that it could be a
possibility... But seems its
2013/2/19 Ramkumar Ramachandra:
What is your usecase? If you have a local branch with the same name
as on the remote, why wouldn't you want to push-to-update it when you
make changes in the branch? In other words, why doesn't push.default
= matching suffice for most practical purposes.
Thanks to Jonathan for the constructive criticism of the tests. Here
is the latest version.
I suspect I'll need to leave it until after David's changes to the
tests are merged into master, unless anyone thinks I should rebase
elsewhere. I think my tests only need a minor update to accommodate
Add the prefix, repository and refspec in the file .gitsubtree when
git subtree add is used. Then when a git subtree push or pull is needed
the repository and refspec from .gitsubtree are used as the default
values.
Having to remember what subtree came from what source is a waste of
developer
add: ensure details are added to .gitsubtree
push: check for a SHA1 update line
pull: add a file on one subtree, push it to a branch, then pull into
another subtree containing the same branch and confirm the files match
add: ensure stale .gitsubtree entry is replaced
Signed-off-by: Paul
Indicate that repository and refspec are now optional on push and pull.
Add notes to add, push and pull about storing values in .gitsubtree
and their use as default values.
Signed-off-by: Paul Campbell pcampb...@kemitix.net
---
contrib/subtree/git-subtree.txt | 13 +
1 file changed,
On Sun, Feb 10, 2013 at 12:24 AM, Duy Nguyen pclo...@gmail.com wrote:
On Sun, Feb 10, 2013 at 12:10 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Finn notes in the commit message that it offers no speedup, because
.gitignore files in every directory still have to be read. I think
this
W. Trevor King wk...@tremily.us writes:
I'm not 100% convinced about this, because the git-rebase.sh uses:
$GIT_DIR/hooks/pre-rebase ${1+$@}
I haven't been able to find documentation for the ${1+$@} syntax.
Is it in POSIX? It's not in the Bash manual:
[...]
In my local tests, it seems
On Tue, Feb 19, 2013 at 02:17:43PM +0100, Thomas Rast wrote:
W. Trevor King wk...@tremily.us writes:
I haven't been able to find documentation for the ${1+$@} syntax.
Is it in POSIX? It's not in the Bash manual:
[...]
In my local tests, it seems equivalent to $@.
It's definitely in the
On Tue, Feb 19, 2013 at 5:24 AM, Zoltan Klinger
zoltan.klin...@gmail.com wrote:
Hi there,
The new git-check-ignore command seg faults when
(1) it is called with single dot path name at $GIT_DIR level _AND_
(2) and .gitignore has at least one directory pattern.
Git version:
On Tue, Feb 19, 2013 at 8:16 PM, Drew Northup n1xim.em...@gmail.com wrote:
Did your testing turn up anything about the amount of time spent
parsing the .gitignore/.gitattributes files? Not the syscall count,
but the actual time spent running the parser (which I presume is
largely CPU-bound).
Fix a corner case where check-ignore would segfault when run with the
'.' argument from the top level of a repository, due to prefix_path()
converting '.' into the empty string. It doesn't make much sense to
call check-ignore from the top level with '.' as a parameter, since
the top-level
test_expect_success_multi() helper function warrants some explanation,
since at first sight it may seem like generic test framework plumbing,
but is in fact specific to testing check-ignore, and allows more
thorough testing of the various output formats without significantly
increase the size of
On Tue, Feb 19, 2013 at 9:25 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Hi,
I have this itch where I want to share my remotes config between
machines. In my fork, I should be able to specify where my upstream
sources are, so remotes get set up automatically when I clone. There
are
Ralf Thielow venit, vidit, dixit 18.02.2013 19:22:
Translate 35 new messages came from git.pot update
in 9caaf23 (l10n: Update git.pot (35 new, 14 removed
messages)).
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
po/de.po | 140
On Tue, Feb 19, 2013 at 05:34:43PM +0700, Nguyen Thai Ngoc Duy wrote:
On Tue, Feb 19, 2013 at 4:25 PM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Hi,
I have this itch where I want to share my remotes config between
machines. In my fork, I should be able to specify where my upstream
Michael J Gruber venit, vidit, dixit 19.02.2013 16:20:
Scott Chacon venit, vidit, dixit 18.02.2013 22:29:
Right now we have:
Dev day: 50
User day: 295
Hack day: 200
I'm not sure what the actual turnout will be, but it looks like it's
going to be pretty massive. I wanted to go through the
Hey,
On Tue, Feb 19, 2013 at 7:41 AM, Michael J Gruber
g...@drmicha.warpmail.net wrote:
Michael J Gruber venit, vidit, dixit 19.02.2013 16:20:
Well, all days are listed as sold out on the eventbrite site. Maybe
it's because eventbrite has trouble connecting to facebook because I
don't have
Juan Pablo juanpablo8...@gmail.com writes:
Hi,
I have a question, can i control the access to specific files or
folders ?? I need that some developers can't see some source files,
thank you very much for your time
No, you can't. You can use e.g. gitolite to set up access control for a
Simon Oosthoek s.oosth...@xs4all.nl writes:
I suppose it would be fine if a patch was sent to update the entire
git-prompt.sh code to be more in line with the Git shell script style...
Please don't. We do not want a style conversion for the sole
purpose of conversion, especially when a
Thomas Rast tr...@inf.ethz.ch writes:
In defense of Thomas, whose project was mentioned earlier as a prime
example of something that is too big:
He's in fact still working on the index-API angle, as part of a thesis
at university.
That is probably a good indicator that it was too big for a
Ramkumar Ramachandra artag...@gmail.com writes:
I was conflating between people who add suggested project and who
act as mentors. I do not think mentors are primarily responsible
for bad suggested projects.
Why do mentors pick badly sketched-out projects to mentor? They're
free to pick
Junio C Hamano gits...@pobox.com writes:
Thomas Rast tr...@inf.ethz.ch writes:
In defense of Thomas, whose project was mentioned earlier as a prime
example of something that is too big:
He's in fact still working on the index-API angle, as part of a thesis
at university.
That is probably
Translate 35 new messages came from git.pot update
in 9caaf23 (l10n: Update git.pot (35 new, 14 removed
messages)).
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
Acked-by: Thomas Rast tr...@inf.ethz.ch
---
Thanks Thomas and Michael for review.
po/de.po | 142
Thomas Rast tr...@student.ethz.ch writes:
$GIT_DIR/hooks/pre-rebase ${1+$@}
...
IIRC this particular usage was designed to suppress warnings about unset
variables.
This is an old-timer's habit to work around buggy implementations of
Bourne shells where they failed to expand $@ to nothing
Translate 5 new messages came from git.pot update in 235537a
(l10n: git.pot: v1.8.2 round 3 (5 new)).
Signed-off-by: Ralf Thielow ralf.thie...@gmail.com
---
po/de.po | 20 +++-
1 file changed, 11 insertions(+), 9 deletions(-)
diff --git a/po/de.po b/po/de.po
index
Jonathan Nieder jrnie...@gmail.com writes:
The downside (not a new problem, but a downside nonetheless) is that
it means the test doesn't demonstrate what --cleanup=verbatim --status
will do.
How about something like this?
Can't we be a bit more robust by not using a hardcoded block of
Jonathan Nieder jrnie...@gmail.com writes:
Brandon Casey wrote:
Hmm, I think the original text was more confusing than I realized. I
think we should reorder the cleanup modes, placing default last, and
then describe default in terms of either strip or whitespace depending
on whether an
Adam Spiers g...@adamspiers.org writes:
test_expect_success_multi() helper function warrants some explanation,
since at first sight it may seem like generic test framework plumbing,
but is in fact specific to testing check-ignore, and allows more
thorough testing of the various output formats
Adam Spiers g...@adamspiers.org writes:
Fix a corner case where check-ignore would segfault when run with the
'.' argument from the top level of a repository, due to prefix_path()
converting '.' into the empty string. It doesn't make much sense to
call check-ignore from the top level with
On Tue, Feb 19, 2013 at 5:06 PM, Juan Pablo juanpablo8...@gmail.com wrote:
I have a question, can i control the access to specific files or folders ?? I
need that some developers can't see some source files, thank you very much
for your time
No, but what you can do is to split these up into
From: Brandon Casey draf...@gmail.com
Signed-off-by: Brandon Casey draf...@gmail.com
---
Ok, here's the updated text. I am not set up to build the documentation,
so I hope someone will test, but looks right to me.
-Brandon
Documentation/git-commit.txt | 28 ++--
1
From: Brandon Casey draf...@gmail.com
Signed-off-by: Brandon Casey draf...@gmail.com
---
[RESEND] I originally specified Junio's address as gits...@pobox.org.
Ok, here's the updated text. I am not set up to build the documentation,
so I hope someone will test, but looks right to me.
-Brandon
From: Brandon Casey draf...@gmail.com
Signed-off-by: Brandon Casey draf...@gmail.com
---
[RESEND] I originally specified Junio's address as gits...@pobox.org.
[RESEND] Sorry, now with the correct address.
Ok, here's the updated text. I am not set up to build the documentation,
so I hope
W. Trevor King wk...@tremily.us writes:
From: W. Trevor King wk...@tremily.us
I think this interface is often more convenient than extended cherry
picking or using 'git format-patch'. In fact, I removed the
cherry-pick section entirely. The entry-level suggestions for
rerolling are now:
On Tue, Feb 19, 2013 at 10:47:04AM -0800, Junio C Hamano wrote:
W. Trevor King wk...@tremily.us writes:
+Sometimes you want to edit a commit deeper in your history. One
+approach is to use `git format-patch` to create a series of patches,
+then reset the state to before the patches:
Thomas Rast tr...@student.ethz.ch writes:
Mildred Ki'Lya mildred...@mildred.fr writes:
The idea is to basically track automatically (in notes, either in the
notes namespace or in another namespace) which repository/remote
contains a commit. When doing git log, we'd see lines with each
Thomas Ackermann th.ac...@arcor.de writes:
Is V4 really recommended for general use?
If you stick to C-git, I do not think there is any reason to avoid
it. It is already a mature technology, the difference between 2 and
4 are so trivial that it is very unlikely for a latent bug to be
hiding in
On Tue, Feb 19, 2013 at 5:54 PM, Junio C Hamano gits...@pobox.com wrote:
Adam Spiers g...@adamspiers.org writes:
Fix a corner case where check-ignore would segfault when run with the
'.' argument from the top level of a repository, due to prefix_path()
converting '.' into the empty string.
W. Trevor King wk...@tremily.us writes:
From: W. Trevor King wk...@tremily.us
Descriptions borrowed from templates/hooks--pre-rebase.sample.
Signed-off-by: W. Trevor King wk...@tremily.us
---
I'm not 100% convinced about this, because the git-rebase.sh uses:
$GIT_DIR/hooks/pre-rebase
Jiang Xin worldhello@gmail.com writes:
Html documents will be installed to root dir (/) no matter what prefix
is set, if run these commands before `make` and `make install-html`:
$ make configure
$ ./configure --prefix=PREFIX
After the installation, all the html documents will
Scott Chacon scha...@gmail.com writes:
On Tue, Feb 19, 2013 at 7:41 AM, Michael J Gruber
g...@drmicha.warpmail.net wrote:
Michael J Gruber venit, vidit, dixit 19.02.2013 16:20:
Well, all days are listed as sold out on the eventbrite site. Maybe
it's because eventbrite has trouble connecting
Fix a corner case where check-ignore would segfault when run with the
'.' argument from the top level of a repository, due to prefix_path()
converting '.' into the empty string. It doesn't make much sense to
call check-ignore from the top level with '.' as a parameter, since
the top-level
Hey,
On Tue, Feb 19, 2013 at 11:19 AM, Junio C Hamano gits...@pobox.com wrote:
Scott Chacon scha...@gmail.com writes:
On Tue, Feb 19, 2013 at 7:41 AM, Michael J Gruber
g...@drmicha.warpmail.net wrote:
Michael J Gruber venit, vidit, dixit 19.02.2013 16:20:
Well, all days are listed as sold
Adam Spiers g...@adamspiers.org writes:
Fair enough. I'll reply to this with a new version.[0]
[0] I wish there was a clean way to include the new version inline,
but as I've noted before, there doesn't seem to be:
http://article.gmane.org/gmane.comp.version-control.git/146110
I
Adam Spiers g...@adamspiers.org writes:
Fix a corner case where check-ignore would segfault when run with the
'.' argument from the top level of a repository, due to prefix_path()
converting '.' into the empty string.
The description does not match what I understand is happening from
the
Ralf Thielow ralf.thie...@gmail.com writes:
msgid You are currently bisecting branch '%s'.
-msgstr Sie sind gerade beim Halbieren.
+msgstr Sie sind gerade beim Halbieren in Zweig '%s'.
I know this one is already in other messages (and also in the Glossary),
but I still find it iffy and I
Hi,
Brandon Casey wrote:
Signed-off-by: Brandon Casey draf...@gmail.com
This renders as
--cleanup=mode
This option determines how the supplied commit message
should be cleaned up before committing. The mode can be
strip, whitespace, verbatim, or
On Tue, Feb 19, 2013 at 12:28 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Hi,
Brandon Casey wrote:
Problems:
* There's a weird extra blank line after default
* Wrong indentation for the final paragraph.
* The linkgit isn't resolved for some reason.
The following fixes it for me.
Brandon Casey bca...@nvidia.com writes:
From: Brandon Casey draf...@gmail.com
Signed-off-by: Brandon Casey draf...@gmail.com
---
[RESEND] I originally specified Junio's address as gits...@pobox.org.
[RESEND] Sorry, now with the correct address.
Ok, here's the updated text. I am not set
W. Trevor King wk...@tremily.us writes:
On Tue, Feb 19, 2013 at 10:47:04AM -0800, Junio C Hamano wrote:
W. Trevor King wk...@tremily.us writes:
+Sometimes you want to edit a commit deeper in your history. One
+approach is to use `git format-patch` to create a series of patches,
+then
Scott Chacon scha...@gmail.com writes:
On Tue, Feb 19, 2013 at 11:19 AM, Junio C Hamano gits...@pobox.com wrote:
Scott Chacon scha...@gmail.com writes:
On Tue, Feb 19, 2013 at 7:41 AM, Michael J Gruber
g...@drmicha.warpmail.net wrote:
Michael J Gruber venit, vidit, dixit 19.02.2013 16:20:
Hi,
On Tue, Feb 19, 2013 at 3:40 AM, Russell Myers mez...@russellmyers.com wrote:
I'm trying to take a Git repository which has never been in Perforce
and push it to Perforce and having difficulty.
[...]
I know that I could create another Git repository that has some
commits in it cloned from
Junio C Hamano gits...@pobox.com writes:
And this sounds like a really bad excuse. If it were it does not
make *any* sense ... because the top level is *never* ignored, then
the patch is a perfectly fine optimization that happens to work
around the problem, but the use of much and typically
On Mon, Feb 18, 2013 at 12:45 PM, Jeff King p...@peff.net wrote:
The thing that makes 2FA usable in the web browser setting is that you
authenticate only occasionally, and get a token (i.e., a cookie) from
the server that lets you have a longer session without re-authenticating.
Right,
Hey,
On Tue, Feb 19, 2013 at 1:26 PM, Junio C Hamano gits...@pobox.com wrote:
Scott Chacon scha...@gmail.com writes:
On Tue, Feb 19, 2013 at 11:19 AM, Junio C Hamano gits...@pobox.com wrote:
Scott Chacon scha...@gmail.com writes:
On Tue, Feb 19, 2013 at 7:41 AM, Michael J Gruber
Jiang Xin worldhello@gmail.com writes:
Html documents will be installed to root dir (/) no matter what prefix
is set, if run these commands before `make` and `make install-html`:
$ make configure
$ ./configure --prefix=PREFIX
After the installation, all the html documents will
On Tue, Feb 19, 2013 at 7:59 PM, Junio C Hamano gits...@pobox.com wrote:
Adam Spiers g...@adamspiers.org writes:
Fix a corner case where check-ignore would segfault when run with the
'.' argument from the top level of a repository, due to prefix_path()
converting '.' into the empty string.
2013/2/20 Junio C Hamano gits...@pobox.com:
Junio C Hamano gits...@pobox.com writes:
After the installation, all the html documents will copy to rootdir (/),
and:
$ git --html-path
PREFIX
$ git help -w something
fatal: 'PREFIX': not a documentation directory.
I am not
On Tue, Feb 19, 2013 at 02:03:01PM -0800, Junio C Hamano wrote:
I started to suspect that may be the right approach. Why not do this?
-- 8 --
From: Junio C Hamano gits...@pobox.com
Date: Tue, 19 Feb 2013 11:56:44 -0800
Subject: [PATCH] name-hash: allow hashing an empty string
Usually we
On Tue, Feb 19, 2013 at 11:56:44AM -0800, Junio C Hamano wrote:
Adam Spiers g...@adamspiers.org writes:
Fair enough. I'll reply to this with a new version.[0]
[0] I wish there was a clean way to include the new version inline,
but as I've noted before, there doesn't seem to be:
Adam Spiers g...@adamspiers.org writes:
OK, thanks for the information. IMHO it would be nice if 'git
format-patch' and 'git am' supported this style of inline patch
inclusion, but maybe there are good reasons to discourage it?
git am --scissors is a way to process such e-mail where the
Git::config() returns `undef` when given keys that do not exist.
Check that the $guitool value is defined to prevent a noisy
Use of uninitialized variable $guitool in length warning.
Signed-off-by: David Aguilar dav...@gmail.com
---
Unchanged from last time but included in the series for
Signed-off-by: David Aguilar dav...@gmail.com
---
t/t7800-difftool.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index eb1d3f8..5b5939b 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800-difftool.sh
@@ -1,6 +1,6 @@
#!/bin/sh
#
-#
Eliminate a lot of redundant work by using test_config().
Catch more return codes by more use of temporary files
and test_cmp.
The original tests relied upon restore_test_defaults()
from the previous test to provide the next test with a sane
environment. Make the tests do their own setup so that
073678b8e6324a155fa99f40eee0637941a70a34 reworked the
mergetools/ directory so that every file corresponds to a
difftool-supported tool. When this happened the defaults
file went away as it was no longer needed by mergetool--lib.
t7800 tests that configured commands can override builtins,
but
Hi,
2013/2/19 Thomas Rast tr...@inf.ethz.ch:
Ralf Thielow ralf.thie...@gmail.com writes:
msgid You are currently bisecting branch '%s'.
-msgstr Sie sind gerade beim Halbieren.
+msgstr Sie sind gerade beim Halbieren in Zweig '%s'.
I know this one is already in other messages (and also in
On Mon, Feb 18, 2013 at 9:02 PM, Jens Lehmann jens.lehm...@web.de wrote:
Am 18.02.2013 20:34, schrieb Jonathan Nieder:
That said, I won't have time to mentor a project on my own. It takes
a lot of time (or luck, to get the student that doesn't need
mentoring).
That's my experience too. Also
On 10/29/2012 01:10 AM, Michael Haggerty wrote:
How do you use GIT_CEILING_DIRECTORIES that the proposed changes cause a
slowdown?
Sorry to bring up this old thread again, but I just realized why my
computer has been acting so slow when I’m not connected to the network.
I put various
On Mon, Feb 18, 2013 at 9:42 AM, Jeff King p...@peff.net wrote:
On Mon, Feb 18, 2013 at 06:23:01PM +0100, Thomas Rast wrote:
* We need an org admin. AFAIK this was done by Peff and Shawn in
tandem last year. Would you do it again?
I will do it again, if people feel strongly about Git
1 - 100 of 107 matches
Mail list logo
