Jiang Xin 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 "":
> 5 new messages.
>
> New l10n updates found in
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 "" this can, depending
on
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 user.
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
> da
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 ra
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 o
This is just write_or_die by another name.
Signed-off-by: Jeff King
---
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 +-
http-back
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
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 wil
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
Thibault Kruse writes:
> Whenever a command description involves "" this can, depending
> on the command, refer to
> 1) a name that, when prepended with "refs/heads/", is a valid ref,
> 2) a name that, when prepended with "refs/heads/" or "refs/tags", is a
> valid ref,
> 3) a name that, when prep
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 resul
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
---
There aren't that many callers of get_remote_heads, so I just added the
optional parameters an
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 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 about
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
---
Just a cleanup for the next patch. We could also just do extra
declarations at the top.
remote-curl.c | 117 +++
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
Jeff King 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 limit was
Jeff King 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 the
On Mon, Feb 18, 2013 at 01:40:17AM -0800, Junio C Hamano wrote:
> Jeff King 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), t
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
Jeff King wrote:
> This is just write_or_die by another name.
>
> Signed-off-by: Jeff King
> ---
> Actually, they are not quite the same. write_or_die will exit(0) when it
> sees EPIPE.
That information definitely belongs in the commit message.
> Which makes me a little nervous.
Me
Hi Junio,
On Mon, Feb 18, 2013 at 10:22 AM, Junio C Hamano wrote:
> Thibault Kruse writes:
>
>> Whenever a command description involves "" this can, depending
>> on the command, refer to
>> 1) a name that, when prepended with "refs/heads/", is a valid ref,
>> 2) a name that, when prepended with
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 funct
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)
> - die("protocol error: bad line length %d", len);
> + die(
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
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
> > ---
> > Actually, they are not quite the same. write_or_die will exit(0) when it
> > sees EPIPE.
>
> That information definit
On Mon, Feb 18, 2013 at 02:12:09AM -0800, Jonathan Nieder wrote:
> 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 in
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 lin
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
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 http://vger.kernel.org/majord
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--;
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
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 h
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 d
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 ad
On Thu, Feb 14, 2013 at 1:57 PM, Junio C Hamano 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 a non-bare but
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'
Sub
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 b/contrib/compl
Am 15.02.2013 20:32, schrieb Junio C Hamano:
> Duy Nguyen writes:
>
>> On Fri, Feb 15, 2013 at 11:52 PM, Junio C Hamano 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 path is excluded, t
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 GS
Thomas Rast 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 various comm
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
sol
> On Mon, 18 Feb 2013 18:46:05 +0100, Thomas Rast
> said:
Thomas>The 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 readability &
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
---
po/de.po | 140 +++
1 file changed, 68 insertions(+), 72 deletions(-)
diff --git a/po/d
Junio C Hamano 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 handle it so I
Junio C Hamano 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 [$there]"
James Nylen 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"
> - commit to "m
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 lis
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: Jonath
Am 17.02.2013 23:32, schrieb Junio C Hamano:
> Jens Lehmann 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 .git/confi
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)".
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 noti
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
Ramkumar Ramachandra 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 demands on thei
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, wrote:
> James Nylen 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 this really be a
Ronan Keryell writes:
>> On Mon, 18 Feb 2013 18:46:05 +0100, Thomas Rast
>> said:
>
> Thomas>The 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 tra
Ramkumar Ramachandra 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 cute idea of its
On Mon, Feb 18, 2013 at 1:52 PM, Jay Townsend 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 www.yubico.com/develop/ and goog
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 resp
Am 18.02.2013 20:45, schrieb Thomas Rast:
> Ramkumar Ramachandra 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 easy to post
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
Ramkumar Ramachandra writes:
[...]
>>> On a related note, I don't like our Wiki. It's down half the time,
>>> and it's very badly maintained. I want to write content for our Wiki
>>> from the comfort of my editor, with version control aiding me. And I
>>> can't stand archaic WikiText.
>>
>> Ag
Junio C Hamano 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 with some
fixes
Ralf Thielow 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 from this l
Paul Campbell 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 can be used to upd
Junio C Hamano 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 handling for 'subt
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
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 administe
On Mon, Feb 18, 2013 at 8:20 PM, wrote:
> Paul Campbell 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
Scott Chacon 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.
[...]
> http:/
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 documented
>w
Here are the subtree fixes I've got with changes in response to
feedback.
--
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 http://vger.kernel.org/majordomo-info.html
From: Techlive Zheng
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
Signed-off-by: David A. Greene
---
contrib/subtree/t/t7900-subtree.sh | 11 +++
1 file changed, 11 insertions(+)
diff --git
From: Techlive Zheng
Previous code does not fulfill Git's whitespace policy.
Signed-off-by: Techlive Zheng
Signed-off-by: David A. Greene
---
contrib/subtree/git-subtree.sh | 68
contrib/subtree/git-subtree.txt| 42 ++---
contrib/subtree/t/t7900-subtree.sh | 326
From: Techlive Zheng
Signed-off-by: Techlive Zheng
Signed-off-by: David A. Greene
---
contrib/subtree/.gitignore |5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/contrib/subtree/.gitignore b/contrib/subtree/.gitignore
index 91360a3..59aeeb4 100644
--- a/contrib/subtr
From: Techlive Zheng
Mostly prepare for the later tests refactoring.
Signed-off-by: Techlive Zheng
Signed-off-by: David A. Greene
---
contrib/subtree/t/t7900-subtree.sh | 256 +++-
1 file changed, 136 insertions(+), 120 deletions(-)
diff --git a/contrib/subtr
From: Techlive Zheng
Signed-off-by: Techlive Zheng
Signed-off-by: David A. Greene
---
contrib/subtree/t/t7900-subtree.sh | 1000 +---
1 file changed, 693 insertions(+), 307 deletions(-)
diff --git a/contrib/subtree/t/t7900-subtree.sh
b/contrib/subtree/t/t7900-
From: Techlive Zheng
'git subtree merge' will fail if the argument of '--prefix' has a slash
appended.
Signed-off-by: Techlive Zheng
Signed-off-by: David A. Greene
---
contrib/subtree/git-subtree.sh |2 +-
contrib/subtree/t/t7900-subtree.sh | 20
2 files changed
From: "David A. Greene"
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
---
contrib/subtree/git-subtree.sh |6 +
contrib/subtree/t/t7900-subtree.sh | 50 +++
From: "David A. Greene"
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
---
contrib/subtree/Makefile |1 -
1 file changed, 1 deletion(-)
diff --git a/contrib/subtree/Makefi
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 jus
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 (thi
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
> s
On Mon, Feb 18, 2013 at 09:52:34PM +0100, Thomas Rast wrote:
> Scott Chacon 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 implementor
Jeff King 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 majordomo info at
Drew Northup 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 http://vger.kernel.or
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 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 most o
Thibault Kruse 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 does not accept all of (3).
That is a prime example of outside "checkout" we give a white lie to
show the most common to help beginner
From: "Alain Kalker"
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
repository.
Philip Oa
Ramkumar Ramachandra 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 demands on thei
Jeff King 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). Git
> al
1 - 100 of 131 matches
Mail list logo
