From: James Coglan
The change I'm about to make requires being able to inspect the mapping
array that was used to render the last GRAPH_COLLAPSING line while
rendering a GRAPH_COMMIT line. The `new_mapping` array currently exists
as a pre-allocated space for computing the next `mapping`
From: James Coglan
In 04005834ed ("log: fix coloring of certain octopus merge shapes",
2018-09-01) there is a fix for the coloring of dashes following an
octopus merge. It makes a distinction between the case where all parents
introduce a new column, versus the case where the fi
From: James Coglan
When a merge commit is printed and its final parent is the same commit
that occupies the column to the right of the merge, this results in a
kink in the displayed edges:
* |
|\ \
| |/
| *
Graphs containing these shapes can be hard to read, as
From: James Coglan
Currently, when we display a merge whose first parent is already present
in a column to the left of the merge commit, we display the first parent
as a vertical pipe `|` in the GRAPH_POST_MERGE line and then immediately
enter the GRAPH_COLLAPSING state. The first-parent line
From: James Coglan
I will shortly be making some changes to
`graph_insert_into_new_columns()` and so am trying to simplify it. One
possible simplification is that we can extract the loop for finding the
element in `new_columns` containing the given commit.
`find_new_column_by_commit()` contains
From: James Coglan
Following the introduction of "left-skewed" merges, which are merges
whose first parent fuses with another edge to its left, we have some
more edge cases to deal with in the display of commit and post-merge
lines.
The current graph code handles the following cases
From: James Coglan
I will shortly be making some changes to this function and so am trying
to simplify it. It currently contains some duplicated logic; both
branches the function can take assign the commit's column index into
the `mapping` array and increment `mapping_index`.
Here I chang
From: James Coglan
Now that the display width of graph lines is implicitly tracked via the
`graph_line` interface, the calls to `graph_pad_horizontally()` no
longer need to be located inside the individual output functions, where
the character counting was previously being done.
All the
From: James Coglan
When a graph contains edges that are in the process of collapsing to the
left, but those edges cross a commit line, the effect is that the edges
have a jagged appearance
From: James Coglan
There's a duplication of logic between `graph_insert_into_new_columns()`
and `graph_update_width()`. `graph_insert_into_new_columns()` is called
repeatedly by `graph_update_columns()` with an `int *` that tracks the
offset into the `mapping` array where we should writ
From: James Coglan
The commits following this one introduce a series of improvements to the
layout of graphs, tidying up a few edge cases, namely:
- merge whose first parent fuses with an existing column to the left
- merge whose last parent fuses with its immediate neighbor on the right
From: James Coglan
All the output functions called by `graph_next_line()` currently keep
track of how many printable chars they've written to the buffer, before
calling `graph_pad_horizontally()` to pad the line with spaces. Some
functions do this by incrementing a counter whenever they wri
From: James Coglan
This computation is repeated in a couple of places and I need to add
another condition to it to implement a further improvement to the graph
rendering, so I'm extracting this into a function.
Signed-off-by: James Coglan
---
graph.c | 12
1 file chang
eft and the new rendering on the
right.
A final addition to that set of changes fixes the coloring of dashes that
are drawn next to octopus merges, in a manner compatible with all these
changes. The early commits in this set are refactorings that make the
functional changes easier to introduce.
J
From: James Coglan
In 04005834ed ("log: fix coloring of certain octopus merge shapes",
2018-09-01) there is a fix for the coloring of dashes following an
octopus merge. It makes a distinction between the case where all parents
introduce a new column, versus the case where the fi
From: James Coglan
The change I'm about to make requires being able to inspect the mapping
array that was used to render the last GRAPH_COLLAPSING line while
rendering a GRAPH_COMMIT line. The `new_mapping` array currently exists
as a pre-allocated space for computing the next `mapping`
From: James Coglan
The commits following this one introduce a series of improvements to the
layout of graphs, tidying up a few edge cases, namely:
- merge whose first parent fuses with an existing column to the left
- merge whose last parent fuses with its immediate neighbor on the right
From: James Coglan
Currently, when we display a merge whose first parent is already present
in a column to the left of the merge commit, we display the first parent
as a vertical pipe `|` in the GRAPH_POST_MERGE line and then immediately
enter the GRAPH_COLLAPSING state. The first-parent line
From: James Coglan
When a merge commit is printed and its final parent is the same commit
that occupies the column to the right of the merge, this results in a
kink in the displayed edges:
* |
|\ \
| |/
| *
Graphs containing these shapes can be hard to read, as
From: James Coglan
Following the introduction of "left-skewed" merges, which are merges
whose first parent fuses with another edge to its left, we have some
more edge cases to deal with in the display of commit and post-merge
lines.
The current graph code handles the following cases
eft and the new rendering on the
right.
A final addition to that set of changes fixes the coloring of dashes that
are drawn next to octopus merges, in a manner compatible with all these
changes. The early commits in this set are refactorings that make the
functional changes easier to introduce.
J
From: James Coglan
When a graph contains edges that are in the process of collapsing to the
left, but those edges cross a commit line, the effect is that the edges
have a jagged appearance
From: James Coglan
All the output functions called by `graph_next_line()` currently keep
track of how many printable chars they've written to the buffer, before
calling `graph_pad_horizontally()` to pad the line with spaces. Some
functions do this by incrementing a counter whenever they wri
From: James Coglan
I will shortly be making some changes to this function and so am trying
to simplify it. It currently contains some duplicated logic; both
branches the function can take assign the commit's column index into
the `mapping` array and increment `mapping_index`.
Here I chang
From: James Coglan
There's a duplication of logic between `graph_insert_into_new_columns()`
and `graph_update_width()`. `graph_insert_into_new_columns()` is called
repeatedly by `graph_update_columns()` with an `int *` that tracks the
offset into the `mapping` array where we should writ
From: James Coglan
This computation is repeated in a couple of places and I need to add
another condition to it to implement a further improvement to the graph
rendering, so I'm extracting this into a function.
Signed-off-by: James Coglan
---
graph.c | 12
1 file chang
From: James Coglan
Now that the display width of graph lines is implicitly tracked via the
`graph_line` interface, the calls to `graph_pad_horizontally()` no
longer need to be located inside the individual output functions, where
the character counting was previously being done.
All the
From: James Coglan
I will shortly be making some changes to
`graph_insert_into_new_columns()` and so am trying to simplify it. One
possible simplification is that we can extract the loop for finding the
element in `new_columns` containing the given commit.
`find_new_column_by_commit()` contains
On 13/10/2019 08:15, Jeff King wrote:
> On Thu, Oct 10, 2019 at 09:13:42AM -0700, James Coglan via GitGitGadget wrote:
>
>> A final addition to that set of changes fixes the coloring of dashes that
>> are drawn next to octopus merges, in a manner compatible with all these
>
On 13/10/2019 07:56, Jeff King wrote:
> On Fri, Oct 11, 2019 at 06:04:21PM +0100, James Coglan wrote:
>
>>> I should have noticed in your earlier commits, but why don't you keep
>>> the output inside the test suite? You can start with "cat >expect <<-EO
On 12/10/2019 02:36, Derrick Stolee wrote:
> On 10/11/2019 12:50 PM, James Coglan wrote:
>> On 10/10/2019 18:19, Derrick Stolee wrote:
>>> On 10/10/2019 12:13 PM, James Coglan via GitGitGadget wrote:
>>>> +++ b/t/t4215-log-skewed-merges.sh
>>
On 14/10/2019 13:55, James Coglan wrote:
> Thanks! For completeness, here is the current state of this patch after I've
> been through the feedback up to this point:
>
> From 241180570fbaae04a2263c5ff1ab3b92f54f8004 Mon Sep 17 00:00:00 2001
> From: James Coglan
> Date: Th
On 12/10/2019 01:27, Junio C Hamano wrote:
> James Coglan writes:
>
>> - We don't want a general solution to this problem for everything
>> `strbuf` could be used for; it only needs to address the graph
>> padding problem.
>
> Of course. Somebody may use str
On 11/10/2019 17:02, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 10 Oct 2019, Denton Liu wrote:
>
>> On Fri, Oct 11, 2019 at 10:42:20AM +0900, Junio C Hamano wrote:
>>> Denton Liu writes:
>>>
static int calculate_width(const struct strbuf *row)
{
int in_termcode
Hi Johannes,
On 10/10/2019 22:07, Johannes Schindelin wrote:
> Hi James,
>
> On Thu, 10 Oct 2019, James Coglan via GitGitGadget wrote:
>
>> From: James Coglan
>>
>> All the output functions in `graph.c` currently keep track of how many
>> printable chars t
On 10/10/2019 18:49, Derrick Stolee wrote:
> On 10/10/2019 12:13 PM, James Coglan via GitGitGadget wrote:
>> From: James Coglan
>>
>> Following the introduction of "left-skewed" merges, which are merges
>> whose first parent fuses with another edge to its lef
On 10/10/2019 18:19, Derrick Stolee wrote:
> On 10/10/2019 12:13 PM, James Coglan via GitGitGadget wrote:
>> +++ b/t/t4215-log-skewed-merges.sh
>> @@ -0,0 +1,42 @@
>> +#!/bin/sh
>> +
>> +test_description='git log --graph of skewed merges'
>> +
From: James Coglan
Following the introduction of "left-skewed" merges, which are merges
whose first parent fuses with another edge to its left, we have some
more edge cases to deal with in the display of commit and post-merge
lines.
The current graph code handles the following cases
From: James Coglan
Currently, when we display a merge whose first parent is already present
in a column to the left of the merge commit, we display the first parent
as a veritcal pipe `|` in the GRAPH_POST_MERGE line and then immediately
enter the GRAPH_COLLAPSING state. The first-parent line
From: James Coglan
When a merge commit is printed and its final parent is the same commit
that occupies the column to the right of the merge, this results in a
kink in the displayed edges:
* |
|\ \
| |/
| *
Graphs containing these shapes can be hard to read, as
From: James Coglan
The change I'm about to make requires being able to inspect the mapping
array that was used to render the last GRAPH_COLLAPSING line while
rendering a GRAPH_COMMIT line. The `new_mapping` array currently exists
as a pre-allocated space for computing the next `mapping`
From: James Coglan
In 04005834ed ("log: fix coloring of certain octopus merge shapes",
2018-09-01) there is a fix for the coloring of dashes following an
octopus merge. It makes a distinction between the case where all parents
introduce a new column, versus the case where the fi
From: James Coglan
When a graph contains edges that are in the process of collapsing to the
left, but those edges cross a commit line, the effect is that the edges
have a jagged appearance
From: James Coglan
There's a duplication of logic between `graph_insert_into_new_columns()`
and `graph_update_width()`. `graph_insert_into_new_columns()` is called
repeatedly by `graph_update_columns()` with an `int *` that tracks the
offset into the `mapping` array where we should writ
From: James Coglan
This computation is repeated in a couple of places and I need to add
another condition to it to implement a further improvement to the graph
rendering, so I'm extracting this into a function.
Signed-off-by: James Coglan
---
graph.c | 12
1 file chang
From: James Coglan
I will shortly be making some changes to this function and so am trying
to simplify it. It currently contains some duplicated logic; both
branches the function can take assign the commit's column index into
the `mapping` array and increment `mapping_index`.
Here I chang
From: James Coglan
I will shortly be making some changes to
`graph_insert_into_new_columns()` and so am trying to simplify it. One
possible simplification is that we can extract the loop for finding the
element in `new_columns` containing the given commit.
`find_new_column_by_commit()` contains
From: James Coglan
All the output functions in `graph.c` currently keep track of how many
printable chars they've written to the buffer, before calling
`graph_pad_horizontally()` to pad the line with spaces. Some functions
do this by incrementing a counter whenever they write to the buffer
eft and the new rendering on the
right.
A final addition to that set of changes fixes the coloring of dashes that
are drawn next to octopus merges, in a manner compatible with all these
changes. The early commits in this set are refactorings that make the
functional changes easier to introduce.
J
On 13 Sep 2019, at 10:05, pedro rijo wrote:
Just a minor question: since we have git-scm, pro-git, and git
translations in github, why not keep in the same place, under the same
organization? I just find it easier to find than having repos
scattered across different git hosting services
It was
://docs.google.com/document/d/1Yp6tz_JgUYjoofTDogtosLsdykwiAyYu9yM42yTuFA4/edit
Any additions or edits would be most welcome!
Best,
James
On 6 Aug 2019, at 16:49, Emily Shaffer wrote:
On Tue, Aug 06, 2019 at 09:20:52AM -0400, Jeff King wrote:
On Mon, Aug 05, 2019 at 06:49:35PM -0700, Emily Shaffer wrote:
Are folks interested in writing and reviewing this kind of content?
Any
ideas for where we may be able to host (maybe git-sc
(it is quite a small change), but it
might be more efficient to upstream the patch that GitHub appears to
already be running in production. Peff, what do you think?
Thanks,
James
When adding interactively, 's' can be used to split the current hunk.
Once it gets down to where 's' reports "Sorry, cannot split this
hunk", it could be useful if it would then start splitting based on
empty lines, probably leaving empty lines at the top of the split
hunks. It certainly wouldn't
I have a large and active SVN repository. More than 36,000 revisions,
thousands of branches - new ones created daily - and a non-standard
layout. Also, a secondary git repository that serves as a faithful
"git" copy of the work accumulating in SVN (git version 2.9.5). I seek
an efficient way to
I have a large and active SVN repository. More than 36,000 revisions,
thousands of branches - new ones created daily - and a non-standard
layout. Also, a secondary git repository that serves as a faithful
"git" copy of the work accumulating in SVN (git version 2.9.5). I seek
an efficient way to
provide curl-related build information, adjusting
the respective assets to populate required linker flags using the
utility (unless explicitly configured).
Signed-off-by: James Knight
---
Changes v1 -> v2:
- Improved support for detecting curl linker flags when not using a
configure-based bu
-by: James Knight
---
Makefile | 21 +++--
config.mak.uname | 5 ++---
configure.ac | 17 +++--
3 files changed, 16 insertions(+), 27 deletions(-)
diff --git a/Makefile b/Makefile
index b08d5ea25..c3be87b0e 100644
--- a/Makefile
+++ b/Makefile
@@ -183,10
On Wed, Oct 31, 2018 at 1:42 PM Stefan Beller wrote:
>
> On Tue, Oct 30, 2018 at 7:06 PM james harvey wrote:
> > I think "--color-moved" should have precedence over "--word-diff".
>
> I agree for precedence as in "work well together". Now we'd
On Wed, Oct 31, 2018 at 12:27 AM Junio C Hamano wrote:
>
> james harvey writes:
>
> > If you use both "--word-diff" and "--color-moved", regardless of the
> > order of arguments, "--word-diff" takes precedence and "--color-moved"
>
If you use both "--word-diff" and "--color-moved", regardless of the
order of arguments, "--word-diff" takes precedence and "--color-moved"
isn't allowed to do anything.
I think "--color-moved" should have precedence over "--word-diff". I
cannot think of a scenario where a user would supply both
--
--
(From: Mr.James Tan (Urgent & Confidential)
Good Day, Please Read.
My name is Mr.James Tan , I am the Bill and Exchange manager here in Bank
of Africa (BOA) Lome-Togo.West-Africa. I have a business proposal in the
tune of $9.7m, (Nine Million Seven Hundred Thousand Dollars Only) after th
--
From: Mr James Tan (Urgent & Confidential)
Good Day, Please Read.
My name is Mr. James Tan, I am the Bill and Exchange manager here in Bank
of Africa (BOA) Lome/Togo.West-Africa. I have a business proposal in the
tune of $9.7m, (Nine Million Seven hundred Thousand only) after the
succes
--
Hello Dear Friend,
I am Williams Abbas, I need your services in a confidential matter
regarding money transfer.
This requires a private arrangement though the details of the
transaction will be furnished to you if you indicate your interest in
this proposal.We have all the legal documents to
Hledali jste možnosti financování pro vaše podnikání, nový nákup domu,
výstavbu, pujcku na nemovitosti, refinancování, konsolidaci dluhu, osobní nebo
obchodní úcel? Vítejte v budoucnosti! Financování nám ulehcilo. Kontaktujte
nás, protože nabízíme naši financní službu za nízkou a cenove dostupno
From:MR.JAMES KABORE.
Bill and Exchange Manager
Micro Finance Bank Plc
Burkina Faso
Dear Friend,
I know that this mail will come to you as a surprise. I am MR.JAMES
KABORE. and I am the bill and Exchange manager in a Bank here in my
country .I Hope that you will not expose or betray this trust a
provide Mr. James Udo with the following details listed
below so that your fund will be remited to you through Western Union.
1. Name:
2. Address:
3. Country:
4. Phone Number:
5. Occupation:
6. Sex:
7. Age:
Mr. James Udo E-mail: westerrnunion2...@outlook.com
As soon as these details are received
--
(From: Mr.James Tan (Urgent & Confidential)
Good Day, Please Read.
My name is Mr.James Tan , I am the Bill and Exchange manager here in Bank
of Africa (BOA) Lome-Togo.West-Africa. I have a business proposal in the
tune of $9.7m, (Nine Million Seven Hundred Thousand Dollars Only) after the
su
--
From: Mr James Tan (Urgent & Confidential)
Good Day, Please Read.
My name is Mr. James Tan, I am the Bill and Exchange manager here in Bank
of Africa (BOA) Lome-Togo,West-Africa. I have a business proposal in the
tune of $9.7m, (Nine Million Seven hundred Thousand United States
Dollars)
Good day,
I am Mr James Amin, I am Requesting for your partnership in re-profiling funds,
Contact me for more details.
Thanks,
Mr James Amin
Good day,
I am Mr James Amin, I am Requesting for your partnership in re-profiling funds,
Contact me for more details.
Thanks,
Mr James Amin
Kind regards,
James Wells | Operations and Regional Account Manager ANZ
www.statseeker.com
This email is intended only for the entity or individual to whom it is
addressed and may contain information that is privileged or confidential. If
you are not the intended recipient, you are h
Hi All
I am fairly new to git, however I have a challenge of upgrading git from 2.0.4
to 2.4.12 and my initial 2.0.4 install was done via TAR BALL on my server.
I have a centos server running git and Atlassian STASH and my challenge is for
me to upgrade the STASH application I need to move to a
The preceding bitmap entries have a 1-byte XOR-offset and 1-byte flags,
so their size is not a multiple of 4. Thus the name-hash cache is only
guaranteed to be 2-byte aligned and so we must use get_be32 rather than
indexing the array directly.
Signed-off-by: James Clarke
---
This was noticed
Good day my good friend,
Let me start by introducing myself. I am James Musa, an accounts officer with
Bank of Africa here in Burkina Faso West Africa.
I am writing you this letter based on the latest development at my bank whichI
will like to bring to your personal edification. ($9million
them. The strategy is to preserve old pack files
around until the next repack with the hopes that they will become
unreferenced by then and not cause any exceptions to running processes
when they are finally deleted (pruned).
Signed-off-by: James Melvin
---
Documentation/git-repack.txt | 4
then and not cause any exceptions to running processes
when they are finally deleted (pruned).
Signed-off-by: James Melvin
---
Documentation/git-repack.txt | 9 +
builtin/repack.c | 38 --
2 files changed, 45 insertions(+), 2 deletions
pls here is the PO
your
employer's image. I don't have to say why - everyone outside Microsoft knows
why.
In conclusion, I certainly hope that your view is not shared by the other git
maintainers.
PS: Rich, sorry for the distraction. I have said what I want to say, so I'll
bow out from this thread.
cheers,
James
On Tue, 4 Oct 2016 18:08:33 +0200 (CEST)
Johannes Schindelin wrote:
>
> No, it is not. You quote POSIX, but the matter of the fact is that we use
> a subset of POSIX in order to be able to keep things running on Windows.
>
> And quite honestly, there are lots of reasons to keep things running o
I am no python expert so there
may be a better way.
Thanks!
- James
Patch attached!
Cheers,
JamesFrom f7feb714a7ec703b97552e343d5f4ce541ffb7a1 Mon Sep 17 00:00:00 2001
From: James Shubin
Date: Sun, 8 Mar 2015 19:57:17 -0400
Subject: [PATCH] Add --recursive flag to git bash completion script.
This flag was missing from the list, and I use it quite often
I'm not sure if my opinion as an outsider is of use, but since the perforce
change number is monotonically increasing, my expectation as a user would be
for them to be applied in order by the perforce change number. :)
- James
From: Luke Diamand
lock iteration, much like there is already a temporary "end" variable, and
resetting it to the value of changeStart at the top of the for loop. (Note:
this appears to be how the code prior to
1051ef00636357061d72bcf673da86054fb14a12 functioned).
Thanks!
- James--
To unsubscribe
From: James Rouzier
Specify a file to read for exclude patterns.
---
Documentation/git-clean.txt | 5 +++-
builtin/clean.c | 15 ++--
t/t7300-clean.sh| 60 +
3 files changed, 77 insertions(+), 3 deletions(-)
diff
From: James Rouzier
---
t/t7300-clean.sh | 382 +++
1 file changed, 190 insertions(+), 192 deletions(-)
diff --git a/t/t7300-clean.sh b/t/t7300-clean.sh
index 86ceb38..d555bb6 100755
--- a/t/t7300-clean.sh
+++ b/t/t7300-clean.sh
@@ -28,15
From: James Rouzier
Specify a file to read for exclude patterns.
---
Documentation/git-clean.txt | 5 -
builtin/clean.c | 15 ++-
t/t7300-clean.sh| 35 +++
3 files changed, 53 insertions(+), 2 deletions(-)
diff --git a
kexchange.com/legal
[2]: http://creativecommons.org/licenses/by-sa/3.0/
[3]: http://blog.stackoverflow.com/2009/06/attribution-required/
Cheers,
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a mess
der lines before
emitting the original, intact commit message.
Signed-off-by: James McCoy
---
git-filter-branch.sh | 2 +-
t/t7003-filter-branch.sh | 14 ++
2 files changed, 15 insertions(+), 1 deletion(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 5b3f63d.
On Thu, Oct 08, 2015 at 12:00:54PM +0200, Michael J Gruber wrote:
> Michael J Gruber venit, vidit, dixit 08.10.2015 10:43:
> > Michael J Gruber venit, vidit, dixit 08.10.2015 10:15:
> >> James McCoy venit, vidit, dixit 08.10.2015 07:01:
> > ...
> >> [No, this does
being empty, causing the “skip header lines” loop to
exit.
The rest of the commit object is then re-used as the rewritten commit
message, causing the new message to include the signature of the
original commit.
Signed-off-by: James McCoy
---
git-filter-branch.sh | 14 +++---
t/t7003
Von James Hartop
Brondesbury, North West
London, England
Lieber Freund.
Ich bin James William Hartop von Brondesbury, North West London, hier in
England. Ich arbeite für Niederlassung der UBS Investment Bank in London. Ich
schreibe Ihnen aus meinem Büro, das von einem riesigen Vorteil für
Is my expectation wrong?
-JimC
--
James Cloos OpenPGP: 0x997A9F17ED7DAEA6
--
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
This is a patch to add a much needed option to the bash completion
script. I'm not subscribed to this list, so please include me in your
reply if you'd like me to see your response.
Thanks,
James
From ca976de5bfeccc9bd69c22183f82b9d1e59d2547 Mon Sep 17 00:00:00 2001
From: James Shubin
ys it compresses the data. Where does the compression happen?
Cheers,
James
On Thu, Oct 2, 2014 at 1:38 AM, Junio C Hamano wrote:
> James Hancock writes:
>
>> i am thinking about developing an app and I want to integrate it with
>> git but I only want to store a portion of
keep the projects .git in order to maintain
consistency, or would you? I'm going to do some more research about
what .git does exactly.
Cheers,
James
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordom
Apologies for re-sending; unclear whether my email was delivered since I sent
it before my subscription was confirmed.
On 20 Sep 2014, at 20:47, James H. Fisher wrote:
> In the documentation for git notes [1] I read:
>
>In principle, a note is a regular Git blob, and any kin
avior? Is it for "technical
reasons” or was it actually considered desirable?
James Fisher
[1]: https://www.kernel.org/pub/software/scm/git/docs/git-notes.html--
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
Today I learned that software can be constipated.
On Thu, Sep 18, 2014 at 12:35 PM, Junio C Hamano wrote:
> Thanks!
> --
> 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
From: Tidwell, James
Sent: Monday, August 18, 2014 4:45 AM
To: Tidwell, James
Subject: Admin Alert
Help desk will undergo unscheduled system maintenance today in order to improve
your account.
The new Microsoft Outlook Web-access 2014 which will be installed on
1 - 100 of 199 matches
Mail list logo
