Jiang Xin worldhello@gmail.com writes:
Please pull l10n updates for git 1.8.2 round 2.
BTW, I find there are new updates in master branch and next branch:
$ po-helper.sh check update
New l10n updates found in master branch of remote kernel:
5 new messages.
New
Hi Duy,
Looking closer at the rest of the docs, I guess it is consistent, but
not terribly helpful.
Throughout the docs (--help and man), it is never very clear what
objects a command
may accept or not. here is what I get from it:
Whenever a command description involves branch this can,
I've taken the following to 'maint', some with minor and obvious
fix-ups:
user-manual: use 'remote add' to setup push URLs
user-manual: give 'git push -f' as an alternative to +master
user-manual: mention 'git remote add' for remote branch config
user-manual: use 'git config --global
On Sun, Feb 17, 2013 at 04:54:43PM -0800, Jonathan Nieder wrote:
My intent was that it followed the error convention of negative is
error, 0 is success, and positive is not used, but reserved for
future use.
From a maintainability perspective, that kind of contract would be
dangerous,
On Sun, Feb 17, 2013 at 05:41:13PM -0800, Jonathan Nieder wrote:
I don't think so. Don't ERR lines appear inside their own packets?
Yes, I misread get_remote_heads for some reason. Thanks for checking.
Thanks for bringing it up. I had not even thought about ERR at all. So
it was luck
The comment describing the packet writing interface was
originally written above packet_write, but migrated to be
above safe_write in f3a3214, probably because it is meant to
generally describe the packet writing interface and not a
single function. Let's move it into the header file, where
users
This is just write_or_die by another name.
Signed-off-by: Jeff King p...@peff.net
---
Actually, they are not quite the same. write_or_die will exit(0) when it
sees EPIPE. Which makes me a little nervous.
builtin/receive-pack.c | 2 +-
builtin/send-pack.c| 2 +-
fetch-pack.c | 2
Originally we had a single function for reading packetized
data: packet_read_line. Commit 46284dd grew a more gentle
form that would return an error instead of dying upon
reading a truncated input stream. However:
1. The two functions were called packet_read and
packet_read_line, with no
If we get a packet from the remote side that is too large to
fit in our buffer, we currently complain protocol error:
bad line length. This is a bit vague. The line length the
other side sent is not bad per se; the actual problem is
that it exceeded our expectation for buffer length.
This will
Originally packets were used just for the line-oriented ref
advertisement and negotiation. These days, we also stuff
packfiles and sidebands into them, and they do not
necessarily represent a line. Drop the _line suffix, as it
is not informative and makes the function names quite long
(especially
The packet_read function reads from a descriptor. The
packet_get_line function is similar, but reads from an
in-memory buffer, and uses a completely separate
implementation. This patch teaches the internal function
backing packet_read to accept either source, and use the
appropriate one. As a
Now that we can read packet data from memory as easily as a
descriptor, get_remote_heads can take either one as a
source. This will allow further refactoring in remote-curl.
Signed-off-by: Jeff King p...@peff.net
---
There aren't that many callers of get_remote_heads, so I just added the
optional
Until recently, get_remote_heads only knew how to read refs
from a file descriptor. To hack around this, we spawned a
thread (or forked a process) to write the buffer back to us.
Now that we can just pass it our buffer directly, we don't
have to use this hack anymore.
Signed-off-by: Jeff King
Jeff King p...@peff.net writes:
On Sun, Feb 17, 2013 at 05:41:13PM -0800, Jonathan Nieder wrote:
I don't think so. Don't ERR lines appear inside their own packets?
Yes, I misread get_remote_heads for some reason. Thanks for checking.
Thanks for bringing it up. I had not even thought
The ref-parsing functions are static. Let's move them up in
the file to be available to more functions, which will help
us with later refactoring.
Signed-off-by: Jeff King p...@peff.net
---
Just a cleanup for the next patch. We could also just do extra
declarations at the top.
remote-curl.c |
When remote-curl receives a list of refs from a server, it
keeps the whole buffer intact. When we get a list command,
we feed the result to get_remote_heads, and when we get a
fetch or push command, we feed it to fetch-pack or
send-pack, respectively.
If the HTTP response from the server is
On Mon, Feb 18, 2013 at 01:29:16AM -0800, Junio C Hamano wrote:
I just checked, and GitHub also does not send flush packets after ERR.
Which makes sense; ERR is supposed to end the conversation.
Hmph. A flush packet was supposed to be a mark to say all the
packets before this one can be
Jeff King p...@peff.net writes:
I'm really tempted to bump all of our 1000-byte buffers to just use
LARGE_PACKET_MAX. If we provided a packet_read variant that used a
static buffer (which is fine for all but one or two callers), then it
would not take much memory...
I thought that 1000-byte
Jeff King p...@peff.net writes:
On Mon, Feb 18, 2013 at 01:29:16AM -0800, Junio C Hamano wrote:
I just checked, and GitHub also does not send flush packets after ERR.
Which makes sense; ERR is supposed to end the conversation.
Hmph. A flush packet was supposed to be a mark to say all
On Mon, Feb 18, 2013 at 01:40:17AM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
I'm really tempted to bump all of our 1000-byte buffers to just use
LARGE_PACKET_MAX. If we provided a packet_read variant that used a
static buffer (which is fine for all but one or two
On Mon, Feb 18, 2013 at 01:49:37AM -0800, Junio C Hamano wrote:
The logic behind the comment we do not buffer, but we should is
that flush tells the receiver that the sending end is done feeding
it a class of data, and the data before flush do not have to reach
the receiver immediately, hence
Hi Junio,
On Mon, Feb 18, 2013 at 10:22 AM, Junio C Hamano gits...@pobox.com wrote:
Thibault Kruse tibokr...@googlemail.com writes:
Whenever a command description involves branch this can, depending
on the command, refer to
1) a name that, when prepended with refs/heads/, is a valid ref,
2)
Jeff King wrote:
Originally we had a single function for reading packetized
data: packet_read_line. Commit 46284dd grew a more gentle
form that would return an error instead of dying upon
reading a truncated input stream. However:
In other words:
Based on the names of two functions
Jeff King wrote:
Originally packets were used just for the line-oriented ref
advertisement and negotiation. These days, we also stuff
packfiles and sidebands into them, and they do not
necessarily represent a line. Drop the _line suffix, as it
is not informative and makes the function names
On Mon, Feb 18, 2013 at 01:56:45AM -0800, Jonathan Nieder wrote:
Jeff King wrote:
This is just write_or_die by another name.
Signed-off-by: Jeff King p...@peff.net
---
Actually, they are not quite the same. write_or_die will exit(0) when it
sees EPIPE.
That information
On Mon, Feb 18, 2013 at 02:15:23AM -0800, Jonathan Nieder wrote:
Jeff King wrote:
--- a/pkt-line.c
+++ b/pkt-line.c
@@ -160,7 +160,8 @@ static int packet_read_internal(int fd, char *buffer,
unsigned size, int gently)
}
len -= 4;
if (len = size)
-
On Mon, Feb 18, 2013 at 02:19:15AM -0800, Jonathan Nieder wrote:
Jeff King wrote:
Originally packets were used just for the line-oriented ref
advertisement and negotiation. These days, we also stuff
packfiles and sidebands into them, and they do not
necessarily represent a line. Drop
Jeff King wrote:
The packet_read function reads from a descriptor.
Ah, so this introduces a new analagous helper that reads from
a strbuf, to avoid the copy-from-async-procedure hack?
[...]
--- a/pkt-line.c
+++ b/pkt-line.c
@@ -103,12 +103,26 @@ static int safe_read(int fd, void *buffer,
Jeff King wrote:
I don't know that this code was hurting anything, but it has always
struck me as ugly and a possible source of error. And now it's gone.
Heh. Belongs in the commit message, presumably.
I don't think the async procedure was very harmful, but it's nice to
avoid the cost of a
On Mon, Feb 18, 2013 at 02:43:50AM -0800, Jonathan Nieder wrote:
Jeff King wrote:
The packet_read function reads from a descriptor.
Ah, so this introduces a new analagous helper that reads from
a strbuf, to avoid the copy-from-async-procedure hack?
Not from a strbuf, but basically, yes.
Jeff King wrote:
remote-curl.c | 23 +--
1 file changed, 13 insertions(+), 10 deletions(-)
I like.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Jeff King wrote:
But is it noisy about a missing pipe? We do not get EPIPE for reading.
Ah, that makes more sense.
[...]
+ len = packet_read_from_buf(line, sizeof(line), last-buf,
last-len);
+ if (len line[len - 1] == '\n')
+ len--;
Was anything
Jeff King wrote:
On Mon, Feb 18, 2013 at 02:19:15AM -0800, Jonathan Nieder wrote:
In combination with patch 3, this changes the meaning of packet_read()
without changing its signature, which could make other patches
cherry-picked on top change behavior in unpredictable ways. :(
So I'd be
On Sun, Feb 17, 2013 at 06:47:09PM -0800, Junio C Hamano wrote:
+Which will adds the following to a file named `.gitconfig` in your
s/adds/add/;
Oops again :p. This change is SOB me.
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see
On Sun, Feb 17, 2013 at 06:58:58PM -0800, Junio C Hamano wrote:
It is easy for me to deal with conflicts in this particular case,
but in general it would have been more straightforward to manage if
these more localized phrasing fixes came earlier and a larger
file-wide cosmetic change was done
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 there? It
doesn't look like you've pushed the last round of maint
On Thu, Feb 14, 2013 at 1:57 PM, Junio C Hamano gits...@pobox.com wrote:
I did not think the detailed discussion belongs there in the first
place, so I re-read the context. I think the only thing the reader
of the user manual needs to learn at that point of the flow is that
they can push to
Hello,
I am running:
git submodule update --recursive
And get the output:
Submodule path 'Submodules/evernote-ios-sdk': checked out
'391ca643c5b1cd02e9fa869a6b0760436ea452ed'
Submodule path 'Submodules/facebook-ios-sdk': checked out
'ada467f754febd4f2871d15943e9be16b323f114'
Minor clean up of if-then nesting in checks for environment variables
and config options. No functional changes.
---
contrib/completion/git-prompt.sh | 27 +--
1 file changed, 13 insertions(+), 14 deletions(-)
diff --git a/contrib/completion/git-prompt.sh
Am 15.02.2013 20:32, schrieb Junio C Hamano:
Duy Nguyen pclo...@gmail.com writes:
On Fri, Feb 15, 2013 at 11:52 PM, Junio C Hamano gits...@pobox.com wrote:
In the current code, we always check if a path is excluded, and when
dealing with DT_REG/DT_LNK, we call treat_file():
* When such a
Hi,
Google announced the 2013 incarnation of the Google Summer of Code
program on Feb 11:
http://www.google-melange.com/gsoc/homepage/google/gsoc2013
Git has taken part in previous years, so I figure somebody should get
the ball rolling again! The following items need to be sorted out:
* We
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 being a part of
it. However, I have gotten a little soured on the
Thomas Rast tr...@inf.ethz.ch writes:
* We should prepare an ideas page[...]
https://github.com/trast/git/wiki/SoC-2013-Ideas
From where I'm currently sitting, I won't have the time to mentor this
year. So my two earlier proposals are essentially up for grabs:
1. Improving parallelism in
Thomas Rast wrote:
2. Improving the `git add -p` interface
* The terminal/line-based interface becomes a problem if diff hunks
are too long to fit in your terminal.
I don't know if it's worth coming up with another interface. The best
On Mon, 18 Feb 2013 18:46:05 +0100, Thomas Rast tr...@student.ethz.ch
said:
ThomasThe actual programming must be done in C using pthreads
Thomas for obvious reasons.
Are there obvious reasons OpenMP would not be enough to do the job?
It looks like a trade-off between the code
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 +++
1 file changed, 68 insertions(+), 72
Junio C Hamano gits...@pobox.com writes:
I also think it would be a good idea for you to learn to push back
to the original authors; fixing problems in patches by others, while
is a good way to learn how their thinking process went, is not
necessarily fun.
Sure, but in this case I said I'd
Junio C Hamano gits...@pobox.com writes:
Git v1.8.2 Release Notes (draft)
Backward compatibility notes
In the upcoming major release (tentatively called 1.8.2), we will
change the behavior of the git push command.
When git push
James Nylen jny...@gmail.com writes:
I don't agree that removing `--annotate` obviates the need for `--unannotate`.
I responded on 1/17 with what I think is a typical and normal use case
for that option:
Sorry, I must have missed that reply.
- add fancylib as a subtree of myprog
-
On Tue, Feb 19, 2013 at 12:14:19AM +0530, Ramkumar Ramachandra wrote:
I'll be frank here. I think the main reason for a student to stick
around is to see more of his code hit `master`. I think it is
absolutely essential to get students constantly post iteration after
iteration on the list.
Hi everyone,
Just would like to request a security feature to help secure peoples
github accounts more by supporting 2 factor authentication like the
yubikey more information can be found from this link
www.yubico.com/develop/ and googles 2 factor authentication. Hope it
gets implemented as
Hi Martin,
Martin Erik Werner wrote:
Minor clean up of if-then nesting in checks for environment variables
and config options. No functional changes.
Yeah, the nesting was getting a little deep. Thanks for the cleanup.
May we have your sign-off?
Once this is signed off,
Reviewed-by:
Am 17.02.2013 23:32, schrieb Junio C Hamano:
Jens Lehmann jens.lehm...@web.de writes:
diff --git a/git-submodule.sh b/git-submodule.sh
index 004c034..0fb6ee0 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -547,6 +548,82 @@ cmd_init()
}
#
+# Unregister submodules from
On 2013-02-17 16:52, Junio C Hamano wrote:
* Color specifiers, e.g. %C(blue)Hello%C(reset), used in the
--format= option of git log and friends can be disabled when
the output is not sent to a terminal by prefixing them with
auto,, e.g. %C(auto,blue)Hello%C(auto,reset).
Thanks so
Hi,
Jeff King wrote:
I will do it again, if people feel strongly about Git being a part of
it. However, I have gotten a little soured on the GSoC experience. Not
because of anything Google has done; it's a good idea, and I think they
do a fine of administering the program. But I have noticed
Am 18.02.2013 16:58, schrieb Will Entriken:
I am running:
git submodule update --recursive
And get the output:
Submodule path 'Submodules/evernote-ios-sdk': checked out
'391ca643c5b1cd02e9fa869a6b0760436ea452ed'
Submodule path 'Submodules/facebook-ios-sdk': checked out
Ramkumar Ramachandra artag...@gmail.com writes:
[corrected David Barr's email address]
Jeff King wrote:
And I do not want to blame the students here (some of whom are on the cc
list :) ). They are certainly under no obligation to stick around after
GSoC ends, and I know they have many
Jeff King wrote:
On Tue, Feb 19, 2013 at 12:14:19AM +0530, Ramkumar Ramachandra wrote:
I'll be frank here. I think the main reason for a student to stick
around is to see more of his code hit `master`. I think it is
absolutely essential to get students constantly post iteration after
On Mon, Feb 18, 2013 at 1:39 PM, gree...@obbligato.org wrote:
James Nylen jny...@gmail.com writes:
- add fancylib as a subtree of myprog
- commit to myprog repo: fancylib: don't crash as much
- split these commits back out to fancylib main repo, and remove
the fancylib: prefix
Should
Ronan Keryell ronan.kery...@silkan.com writes:
On Mon, 18 Feb 2013 18:46:05 +0100, Thomas Rast tr...@student.ethz.ch
said:
ThomasThe actual programming must be done in C using pthreads
Thomas for obvious reasons.
Are there obvious reasons OpenMP would not be enough to do the
Ramkumar Ramachandra artag...@gmail.com writes:
* Cannot look at the diff in word-diff mode (and apply it normally).
[...]
Also: Having to figure out, heuristically, when to actually turn it on
might be a worthwhile feature, especially for services like GitHub.
Actually that's a pretty
On Mon, Feb 18, 2013 at 1:52 PM, Jay Townsend townsend...@hotmail.com wrote:
Hi everyone,
Just would like to request a security feature to help secure peoples github
accounts more by supporting 2 factor authentication like the yubikey more
information can be found from this link
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 #git-devel. Mentors
serve a different purpose; their primary
Am 18.02.2013 20:45, schrieb Thomas Rast:
Ramkumar Ramachandra artag...@gmail.com writes:
What's the harm of including something estimated to take 80% of a
summer?
Maybe even less than 80%.
I didn't regret at all having split the summer's topic I mentored
into smaller pieces. That made it
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 I think it really makes sense to have a
co-mentor so you can balance the
Junio C Hamano gits...@pobox.com writes:
This looks to be of mixed quality. The earlier ones look fairly
finished, while the later ones not so much.
I am tempted to take up to 06/13 and advance them to 'next', without
the rest.
Can you let me know what you've taken up? I have a new set
Ralf Thielow ralf.thie...@gmail.com writes:
#: builtin/branch.c:888
msgid too many branches for a rename operation
-msgstr
+msgstr zu viele Zweige angegeben
You lost the rename bit, was that on purpose?
Other than that, ACK.
--
Thomas Rast
trast@{inf,student}.ethz.ch
--
To unsubscribe
Paul Campbell pcampb...@kemitix.net writes:
Subsequent git subtree push/pull operations now default to the values
stored in .gitsubtree, unless overridden from the command line.
The .gitsubtree file should be tracked as part of the repo as it
describes where parts of the tree came from and
Junio C Hamano gits...@pobox.com writes:
* dg/subtree-fixes (2013-02-05) 6 commits
(merged to 'next' on 2013-02-09 at 8f19ebe)
+ contrib/subtree: make the manual directory if needed
+ contrib/subtree: honor DESTDIR
+ contrib/subtree: fix synopsis
+ contrib/subtree: better error
On Mon, Feb 18, 2013 at 02:54:30PM -0500, James Nylen wrote:
Just would like to request a security feature to help secure peoples github
accounts more by supporting 2 factor authentication like the yubikey more
information can be found from this link www.yubico.com/develop/ and googles
2
Jonathan Nieder wrote:
Hi,
Jeff King wrote:
I will do it again, if people feel strongly about Git being a part of
it. However, I have gotten a little soured on the GSoC experience. Not
because of anything Google has done; it's a good idea, and I think they
do a fine of administering the
On Mon, Feb 18, 2013 at 8:20 PM, gree...@obbligato.org wrote:
Paul Campbell pcampb...@kemitix.net writes:
Subsequent git subtree push/pull operations now default to the values
stored in .gitsubtree, unless overridden from the command line.
The .gitsubtree file should be tracked as part of
Scott Chacon scha...@gmail.com writes:
We're starting off in Berlin, May 9-11th. GitHub has secured
conference space at the Radisson Blu Berlin for those days. I have a
smaller room for the first day so we can get 30-40 Git implementors
together to talk about the future of Git and whatnot.
From: Techlive Zheng techlivezh...@gmail.com
Use %B to format the commit message and body to avoid an extra newline
if a commit only has a subject line.
Signed-off-by: Techlive Zheng techlivezh...@gmail.com
Signed-off-by: David A. Greene gree...@obbligato.org
---
From: Techlive Zheng techlivezh...@gmail.com
Previous code does not fulfill Git's whitespace policy.
Signed-off-by: Techlive Zheng techlivezh...@gmail.com
Signed-off-by: David A. Greene gree...@obbligato.org
---
contrib/subtree/git-subtree.sh | 68
contrib/subtree/git-subtree.txt
From: Techlive Zheng techlivezh...@gmail.com
Signed-off-by: Techlive Zheng techlivezh...@gmail.com
Signed-off-by: David A. Greene gree...@obbligato.org
---
contrib/subtree/.gitignore |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/contrib/subtree/.gitignore
From: Techlive Zheng techlivezh...@gmail.com
Mostly prepare for the later tests refactoring.
Signed-off-by: Techlive Zheng techlivezh...@gmail.com
Signed-off-by: David A. Greene gree...@obbligato.org
---
contrib/subtree/t/t7900-subtree.sh | 256 +++-
1 file
From: Techlive Zheng techlivezh...@gmail.com
Signed-off-by: Techlive Zheng techlivezh...@gmail.com
Signed-off-by: David A. Greene gree...@obbligato.org
---
contrib/subtree/t/t7900-subtree.sh | 1000 +---
1 file changed, 693 insertions(+), 307 deletions(-)
diff
From: Techlive Zheng techlivezh...@gmail.com
'git subtree merge' will fail if the argument of '--prefix' has a slash
appended.
Signed-off-by: Techlive Zheng techlivezh...@gmail.com
Signed-off-by: David A. Greene gree...@obbligato.org
---
contrib/subtree/git-subtree.sh |2 +-
From: David A. Greene gree...@obbligato.org
Remove --annotate. This obviates the need for an --unannotate
command. We really want a more generalized commit message rewrite
mechanism.
Signed-off-by: David A. Greene gree...@obbligato.org
---
contrib/subtree/git-subtree.sh |6 +
From: David A. Greene gree...@obbligato.org
There should be no need to remove 'mainline' nd 'subproj'
in the Makefile as these should always be created under the
test directory.
Signed-off-by: David A. Greene gree...@obbligato.org
---
contrib/subtree/Makefile |1 -
1 file changed, 1
On Tue, Feb 19, 2013 at 02:14:54AM +0530, Ramkumar Ramachandra wrote:
- assimilating the distro builds: make deb-pkg, make rpm-pkg,
etc along the same lines as the linux kernel's script/package/,
to help people get recent git installed when they want it
Overkill. I just symlink
Ramkumar Ramachandra wrote:
Jonathan Nieder wrote:
- cross-compilable git
Why, exactly? Git for embedded devices?
My personal motivation would be building Git for Windows while
spending as little time on Windows as possible. People deploying git
to 32-bit x86, 64-bit x86, and ARM (think
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 #git-devel. Mentors
serve
On Mon, Feb 18, 2013 at 09:52:34PM +0100, Thomas Rast wrote:
Scott Chacon scha...@gmail.com writes:
We're starting off in Berlin, May 9-11th. GitHub has secured
conference space at the Radisson Blu Berlin for those days. I have a
smaller room for the first day so we can get 30-40 Git
Jeff King p...@peff.net writes:
But it's easy to do (1), and it starts the clock ticking for
the 1000-byte readers to become obsolete.
Yup, I agree with that goal.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
Drew Northup n1xim.em...@gmail.com writes:
This looks safe to me, with the minor nit that ofthe (of the)
isn't one word.
Thanks; typo corrected.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at
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 Dev day
signups and figure out if everyone really belongs there (is an actual
contributor to a core git project)
On Mon, Feb 18, 2013 at 01:25:35PM -0800, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
But it's easy to do (1), and it starts the clock ticking for
the 1000-byte readers to become obsolete.
Yup, I agree with that goal.
Having just looked at the pkt-line callers a lot, I think
Thibault Kruse tibokr...@googlemail.com writes:
I am not sure why you meant to treat (2) and (3) differently,
though. Care to elaborate?
As in my example, git clone --branch branch does not accept all of (3).
That is a prime example of outside checkout we give a white lie to
show the most
From: Alain Kalker a.c.kal...@gmail.com
Sent: Sunday, February 17, 2013 7:28 PM
From the current documentation for git-bundle(1), it may not be clear
for
users unfamilliar with Git, how to create a bundle which can be used
for
backup purposes, or, more generally, to clone to a completely new
Ramkumar Ramachandra artag...@gmail.com writes:
[corrected David Barr's email address]
Jeff King wrote:
And I do not want to blame the students here (some of whom are on the cc
list :) ). They are certainly under no obligation to stick around after
GSoC ends, and I know they have many
Jeff King p...@peff.net writes:
This is not related to GSoC anymore, but I think handling multiple
versions is already pretty easy. You can just install to
$HOME/local/git/$TAGNAME or similar, and then symlink the bin/git
binary from there into your PATH as git.$TAGNAME (e.g., git.v1.7.8).
David A. Greene gree...@obbligato.org writes:
From: Techlive Zheng techlivezh...@gmail.com
Use %B to format the commit message and body to avoid an extra newline
if a commit only has a subject line.
Signed-off-by: Techlive Zheng techlivezh...@gmail.com
Signed-off-by: David A. Greene
David A. Greene gree...@obbligato.org writes:
From: Techlive Zheng techlivezh...@gmail.com
Signed-off-by: Techlive Zheng techlivezh...@gmail.com
Signed-off-by: David A. Greene gree...@obbligato.org
---
contrib/subtree/.gitignore |5 ++---
1 file changed, 2 insertions(+), 3
David A. Greene gree...@obbligato.org writes:
From: Techlive Zheng techlivezh...@gmail.com
Mostly prepare for the later tests refactoring.
Signed-off-by: Techlive Zheng techlivezh...@gmail.com
Signed-off-by: David A. Greene gree...@obbligato.org
---
Applying: contrib/subtree: Code
On Mon, 2013-02-18 at 21:31 +0100, Simon vanaf Telefoon wrote:
Hi all, sorry for top posting :-( blame the phone and k9
I have a small issue with the use of test instead of [
If that only applies to this section of the entire file.
Coding style has some value.
Combining nested ifs with
From: Martin Erik Werner martinerikwer...@gmail.com
Minor clean up of if-then nesting in checks for environment variables
and config options. No functional changes.
Signed-off-by: Martin Erik Werner martinerikwer...@gmail.com
---
contrib/completion/git-prompt.sh | 27
Jeff King wrote:
On Mon, Feb 18, 2013 at 11:34:24AM -0800, Jonathan Nieder wrote:
Some potential projects (unfiltered --- please take them with a grain
of salt):
[...]
- collaborative notes editing: fix the default notes refspec,
make sure the notes pull workflow works well and is
Martin Erik Werner martinerikwer...@gmail.com writes:
On Mon, 2013-02-18 at 21:31 +0100, Simon vanaf Telefoon wrote:
Hi all, sorry for top posting :-( blame the phone and k9
I have a small issue with the use of test instead of [
If that only applies to this section of the entire file.
1 - 100 of 124 matches
Mail list logo
