Antonio Ospite writes:
> Now that 'config_from_gitmodules' is not used in the open, it can be
> marked as private.
Nice ;-)
Now that 'config_from_gitmodules' is not used in the open, it can be
marked as private.
Hopefully this will prevent its usage for retrieving arbitrary
configuration form the '.gitmodules' file.
Signed-off-by: Antonio Ospite
---
submodule-config.c | 8
sub
Now that 'config_from_gitmodules' is not used in the open, it can be
marked as private.
Hopefully this will prevent its usage for retrieving arbitrary
configuration form the '.gitmodules' file.
Signed-off-by: Antonio Ospite
---
submodule-config.c | 8
sub
The reason callers have to call this is to make sure either packed_git
or packed_git_mru pointers are initialized since we don't do that by
default. Sometimes it's hard to see this connection between where the
function is called and where packed_git pointer is used (sometimes in
separate functions)
d and where packed_git pointer is used (sometimes in
> separate functions).
>
> Keep this dependency internal because now all access to packed_git and
> packed_git_mru must go through get_xxx() wrappers.
Ahh now I understand the rational for trying to make it "private"
On Sat, 3 Mar 2018 18:36:37 +0700
Nguyễn Thái Ngọc Duy wrote:
> The reason callers have to call this is to make sure either packed_git
> or packed_git_mru pointers are initialized since we don't do that by
> default. Sometimes it's hard to see this connection between where the
> function is cal
The reason callers have to call this is to make sure either packed_git
or packed_git_mru pointers are initialized since we don't do that by
default. Sometimes it's hard to see this connection between where the
function is called and where packed_git pointer is used (sometimes in
separate functions)
Jonathan Tan writes:
> Move the definition of the transport-specific functions provided by
> transports, whether declared in transport.c or transport-helper.c, into
> an internal header. This means that transport-using code (as opposed to
> transport-declaring code) can no longer access these fun
truct transport_ops inlined into struct transport", 2007-09-19).
However, the scope of the involved variables was neither affected nor
discussed in that commit, and I think that the advantages in making
those functions more private outweigh the advantages described in that
commit's commit m
--
Diese E-Mail fordert Sie strikt auf, sich für eine große Investition mit
mir zusammenzutun, um weitere Informationen zu erhalten.
Mit freundlichen Grüßen,
Khvostova Zhanna
Diese E-Mail fordert Sie strikt auf, sich für eine große Investition mit
mir zusammenzutun, um weitere Informationen zu erhalten.
Mit freundlichen Grüßen,
Khvostova Zhanna
On 09/17, Ramsay Jones wrote:
>
> Signed-off-by: Ramsay Jones
> ---
>
> Hi Brandon,
>
> If you need to re-roll your 'bw/protocol-v1' branch, could you please
> squash this into the relevant patch (commit 45954f179e, "protocol:
> introduce protocol extention mechanisms", 13-09-2017).
>
> This a
Signed-off-by: Ramsay Jones
---
Hi Brandon,
If you need to re-roll your 'bw/protocol-v1' branch, could you please
squash this into the relevant patch (commit 45954f179e, "protocol:
introduce protocol extention mechanisms", 13-09-2017).
This assumes you agree that this symbol does not need to b
licit pruning happening due to some
> configuration option or the specific commands I'm using?
No, that prune is fetching from your upstream into the bridge repo. So
it is dropping refs from the bridge that went away upstream. My
assumption is that your "private" branches are n
removing "--prune"
from the remove update? I did that, but it still deletes my test-branch
on push. Is there an implicit pruning happening due to some
configuration option or the specific commands I'm using?
> 2. Use two different namespaces for the synced branches and the
>
ending on the patterns that may or may not be a
problem).
2. Use two different namespaces for the synced branches and the
private ones (e.g., refs/mirror/* in addition to your branches in
refs/heads/*). The obvious downside is that anybody cloning your
downstream mirror doesn
Hello,
Let's say there'a s hosting service hosting a repository which I want
to self-host. I don't just want to do a mirror, but I want to keep it
in sync (using a cronjob). In addition, I want to have private branches
on the self-hosted repository. (In this particular cas
The parse_ref_filter_atom() function really shouldn't be
exposed outside of ref-filter.c; its return value is an
integer index into an array that is private in that file.
Since the previous commit removed the sole external caller
(and replaced it with a public function at a more
appropri
The following functions currently don't need to be exposed:
* ref_store_init()
* lookup_ref_store()
That might change in the future, but for now make them private.
Signed-off-by: Michael Haggerty
---
refs.c | 19 +--
refs/refs-internal.h
Hello, I am Carlos Zulueta Secretary to Dr. Gertjan Vlieghe (Bank Of
England), we have an inheritance of a deceased client with your
surname Contact Dr. Gertjan Vlieghe With your: Full Name, Tel Number,
Age, Occupation and Address through email: gvlie...@yandex.com
--
Jeff King writes:
> So I think the in-between answer is "it is OK to push to an
> untrustworthy place, but do not do it from a repo that may contain
> secret contents".
Yes, that sounds like a sensible piece of advice to give to the
readers.
On Mon, 2016-11-14 at 11:00 -0800, Junio C Hamano wrote:
> Matt McCutchen writes:
>
> >
> > >
> > > Yup, and then "do not push to untrustworthy place without
> > > checking
> > > what you are pushing", too?
> >
> > If
On Mon, Nov 14, 2016 at 11:00:04AM -0800, Junio C Hamano wrote:
> Matt McCutchen writes:
>
> >> Yup, and then "do not push to untrustworthy place without checking
> >> what you are pushing", too?
> >
> > If there is no private data in the reposit
Matt McCutchen writes:
>> Yup, and then "do not push to untrustworthy place without checking
>> what you are pushing", too?
>
> If there is no private data in the repository, then there is no need
> for the user to check what they are pushing. As I've indic
@
> > +SECURITY
> > +
> > +The fetch and push protocols are not designed to prevent a
> > malicious
> > +server from stealing data from your repository that you did not
> > intend to
> > +share. The possible attacks are similar to the ones described i
d push protocols are not designed to prevent a malicious
> +server from stealing data from your repository that you did not intend to
> +share. The possible attacks are similar to the ones described in the
> +"SECURITY" section of linkgit:gitnamespaces[7]. If you have private data
&
s and recommend using separate repositories for private data and
interaction with untrusted servers.
Signed-off-by: Matt McCutchen
---
And here's a proposed patch. Based on the maint branch, ac84098.
Documentation/fetch-push-security.txt | 9 +
Documentation/git-fetch.txt
On Mon, Mar 14, 2016 at 10:22:43AM +0300, Никита Соболев wrote:
> Robin, thank you for interest.
>
> I have not seen 'pwstore' before, but I don't like the idea to store
> headers inside the file. As it might break things. But I love the idea
> of groups and access rights. It is a direction I woul
Robin, thank you for interest.
I have not seen 'pwstore' before, but I don't like the idea to store
headers inside the file. As it might break things. But I love the idea
of groups and access rights. It is a direction I would like to follow.
Also I like your suggestion about the key's white-list.
Have you seen the much older pwstore tool?
https://github.com/formorer/pwstore
It does have some notable features missing from git-secret and similar
tools to this day.
- Whitelist of trusted keys to detect addition of unexpected keys.
- Specify what users/groups have access to any given file (via
There’s a known problem in server configuration and deploying, when
you have to store your private data such as: database passwords,
application secret-keys, OAuth secret keys and so on, outside of the
git repository. Even if this repository is private, it is a security
risk to just publish them
ning a repository, I attempted
> to "git pull" a private repository from GitHub.
Are you using Git CMD? It is rather crucial to get such details right.
> 15:55:58.615147 git.c:348 trace: built-in: git 'pull'
> 15:55:58.617147 run-command.c:343 trace: r
Hi,
I have recently downloaded 64-bit Git for Windows (the file I downloaded
was "Git-2.7.2-64-bit.exe"). This reports a version string of "git
version 2.7.2.windows.1"
Using it from the command line, after cloning a repository, I attempted
to "git pull" a privat
On Wed, Dec 09, 2015 at 02:29:12PM -0800, Stefan Beller wrote:
> On Wed, Dec 9, 2015 at 2:24 PM, Jeff King wrote:
> > On Wed, Dec 09, 2015 at 05:20:41PM -0500, Jeff King wrote:
> >
> >> Of course that is a bitter pill to swallow if you have reasons for
> >> wanting to use the old sha1s. E.g., you
On Wed, Dec 9, 2015 at 2:24 PM, Jeff King wrote:
> On Wed, Dec 09, 2015 at 05:20:41PM -0500, Jeff King wrote:
>
>> Of course that is a bitter pill to swallow if you have reasons for
>> wanting to use the old sha1s. E.g., you have internal development
>> proceeding against the old tree and want to
On Wed, Dec 09, 2015 at 05:20:41PM -0500, Jeff King wrote:
> Of course that is a bitter pill to swallow if you have reasons for
> wanting to use the old sha1s. E.g., you have internal development
> proceeding against the old tree and want to share a truncated version
> with the public.
After re-r
On Wed, Dec 09, 2015 at 02:45:44PM +0100, Jörn Hees wrote:
> I've been hacking away on a library for quite some time and have a lot of
> commits in my private repository:
>
> A -> B -> C -> D -> E
>
> Finally, I'm nearing completion of a first versi
On 09/12, Jörn Hees wrote:
Hi,
I've been hacking away on a library for quite some time and have a lot
of commits in my private repository:
A -> B -> C -> D -> E
Finally, I'm nearing completion of a first version, and want to publish
it to a remote called public from
Hi,
I've been hacking away on a library for quite some time and have a lot of
commits in my private repository:
A -> B -> C -> D -> E
Finally, I'm nearing completion of a first version, and want to publish it to a
remote called public from D onward keeping A..C to my
my private Email: ltuala...@gmail.com, I shall give
you comprehensive details.
Best Regard.
Lopati T
--
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
It is no longer called from outside of the refs module. Also move its
docstring and change it to imperative voice.
Signed-off-by: Michael Haggerty
---
refs.c | 9 -
refs.h | 11 ---
2 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/refs.c b/refs.c
index 19afc4d..b2
It is no longer called from outside of the refs module. Also move its
docstring and change it to imperative voice.
Signed-off-by: Michael Haggerty
---
refs.c | 9 -
refs.h | 11 ---
2 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/refs.c b/refs.c
index 5386077..83
It is no longer called from outside of the refs module. Also move its
docstring and change it to imperative voice.
Signed-off-by: Michael Haggerty
---
refs.c | 9 -
refs.h | 11 ---
2 files changed, 8 insertions(+), 12 deletions(-)
diff --git a/refs.c b/refs.c
index a10aba8..dc
Jeff King writes:
> On Wed, Jan 14, 2015 at 03:40:45PM -0800, Junio C Hamano wrote:
>
>> Here are a handful of patches to make symbols that are only used
>> within a .c file as static. This is not the kind of changes we
>> would want to do in the pre-release freeze period, and it is just
>> for
On Wed, Jan 14, 2015 at 03:40:45PM -0800, Junio C Hamano wrote:
> Here are a handful of patches to make symbols that are only used
> within a .c file as static. This is not the kind of changes we
> would want to do in the pre-release freeze period, and it is just
> for reference. I may later com
Regarding patch 1 - 9:
Reviewed-by: Stefan Beller
for what it's worth.
--
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
Here are a handful of patches to make symbols that are only used
within a .c file as static. This is not the kind of changes we
would want to do in the pre-release freeze period, and it is just
for reference. I may later come back to them after 2.3 final is
tagged.
Note that I did not blindly ma
My name is Gatan Magsino, I work with Mediterranean Bank in Malta. Can i trust
you with a business worth $8.3M USD? Please reply ONLY to my private email:
mga...@rogers.com<mailto:mga...@rogers.com> for more information
--
To unsubscribe from this list: send the line "unsubscribe
On Tue, Dec 02, 2014 at 09:27:34PM -0800, Jonathan Nieder wrote:
> The old external callers now use the message passed back by
> hold_lock_file_for_update / hold_lock_file_for_append instead of
> trying to interpret errno.
>
> Signed-off-by: Jonathan Nieder
> ---
> That's the end of the series.
The old external callers now use the message passed back by
hold_lock_file_for_update / hold_lock_file_for_append instead of
trying to interpret errno.
Signed-off-by: Jonathan Nieder
---
That's the end of the series. Thanks for reading.
Thoughts?
lockfile.c | 42 +-
We no longer need to expose the ref_lock structure to any external callers.
Make it private to refs.c.
Signed-off-by: Ronnie Sahlberg
---
refs.c | 9 +
refs.h | 9 -
2 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/refs.c b/refs.c
index 918cda3..8129b20 100644
Thanks very much for the feedback and implementation suggestions.
> If the only thing you are interested in supporting is a one-shot
> invocation, i.e. giving which identity file to use from the command
> line when you run either "git push" or "git fetch",
Yes, this is the new option that could b
Jeff King writes:
> We already have GIT_SSH, so I would expect:
>
> GIT_SSH='ssh -i $HOME/.ssh/id_for_example_com' git push
>
> to work. But sadly, GIT_SSH does not use the shell, unlike most other
> configure git commands. :(
You read me correctly ;-)
> We could consider it a consistency bug
On Wed, Sep 11, 2013 at 09:39:55PM -0700, Junio C Hamano wrote:
> If the only thing you are interested in supporting is a one-shot
> invocation, i.e. giving which identity file to use from the command
> line when you run either "git push" or "git fetch", I suspect that
> you could play with GIT_SS
Breck Yunits writes:
> It would be very helpful if you could specify the path to the private
> key to use for ssh remotes just like in ssh.
You could add a support for the "remote..sshIdentityFile"
configuration variable, i.e.
[remote "origin"
It would be very helpful if you could specify the path to the private
key to use for ssh remotes just like in ssh.
```
git push origin master -i 'path_to_key'
```
Althought there are workarounds involving ssh config, if you have a
server that has hundreds of git repos, each with the o
2013/9/11 Stefano Lattarini :
> Hi Elia. Sorry, but I have to give my NAK to this patch.
>
I hold in great consideration the comments of Stephen in this area.
>
> On 09/11/2013 04:46 PM, Elia Pinto wrote:
>>
>> Git use, as many project that use autoconf, private m4 macr
Hi Elia. Sorry, but I have to give my NAK to this patch.
On 09/11/2013 04:46 PM, Elia Pinto wrote:
Git use, as many project that use autoconf, private m4 macros.
When not using automake, and just relying on autoconf, the macro
files are not picked up by default.
A possibility, as git do
Git use, as many project that use autoconf, private m4 macros.
When not using automake, and just relying on autoconf, the macro
files are not picked up by default.
A possibility, as git do today, is to put the private m4 macro
in the configure.ac file, so they will copied over the final
Since 664059fb62 (Felipe Contreras, Apr 17 2013, transport-helper: update
remote helper namespace), a 'push' operation on a remote helper updates
the private ref by default. This is often a good thing, but it can also
be desirable to disable this update to force the next 'pull&#x
Since 664059fb62 (Felipe Contreras, Apr 17 2013, transport-helper: update
remote helper namespace), a 'push' operation on a remote helper updates
the private ref by default. This is often a good thing, but it can also
be desirable to disable this update to force the next 'pull&#x
On Mon, Sep 2, 2013 at 2:19 AM, Matthieu Moy wrote:
> Since 664059fb62 (Felipe Contreras, Apr 17 2013, transport-helper: update
> remote helper namespace), a 'push' operation on a remote helper updates
> the private ref by default. This is often a good thing, but it can als
We used to update the private ref ourselves, but this update is now done
by default (since 664059fb62).
Signed-off-by: Matthieu Moy
---
contrib/mw-to-git/git-remote-mediawiki.perl | 1 -
1 file changed, 1 deletion(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git
Since 664059fb62 (Felipe Contreras, Apr 17 2013, transport-helper: update
remote helper namespace), a 'push' operation on a remote helper updates
the private ref by default. This is often a good thing, but it can also
be desirable to disable this update to force the next 'pull&#x
-mediawiki.perl
+++ b/contrib/mw-to-git/git-remote-mediawiki.perl
@@ -590,6 +590,9 @@ sub mw_capabilities {
print {*STDOUT} "import\n";
print {*STDOUT} "list\n";
print {*STDOUT} "push\n";
+ if ($dumb_push) {
+ print
On Thu, Aug 29, 2013 at 1:58 PM, Matthieu Moy wrote:
> Since 664059fb62 (Felipe Contreras, Apr 17 2013, transport-helper: update
> remote helper namespace), a 'push' operation on a remote helper updates
> the private ref by default. This is often a good thing, but it can als
Matthieu Moy writes:
> We used to update the private ref ourselves, but this update is now done
> by default (since 664059fb62).
>
> Signed-off-by: Matthieu Moy
> ---
Thanks; will queue all four.
--
To unsubscribe from this list: send the line "unsubscribe git" in
UT} "list\n";
> print {*STDOUT} "push\n";
> + if ($dumb_push) {
> + print {*STDOUT} "dont-update-private\n";
> + }
> print {*STDOUT} "\n";
> return;
> }
--
To unsubscribe from this list: send the li
We used to update the private ref ourselves, but this update is now done
by default (since 664059fb62).
Signed-off-by: Matthieu Moy
---
contrib/mw-to-git/git-remote-mediawiki.perl | 1 -
1 file changed, 1 deletion(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
b/contrib/mw-to-git
Since 664059fb62 (Felipe Contreras, Apr 17 2013, transport-helper: update
remote helper namespace), a 'push' operation on a remote helper updates
the private ref by default. This is often a good thing, but it can also
be desirable to disable this update to force the next 'pull&#x
-to-git/git-remote-mediawiki.perl
@@ -590,6 +590,9 @@ sub mw_capabilities {
print {*STDOUT} "import\n";
print {*STDOUT} "list\n";
print {*STDOUT} "push\n";
+ if ($dumb_push) {
+ print {*STDOUT} "dont-update-private\n"
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> git-remote-mediawiki is kind of a special case, as the remote side uses
>> a very different data model, hence it can make sense to export+reimport
>> to get locally what the remote side received.
>
> Hmm, I am not sure how export+reimport would
would look like:
>
> This is exactly what I meant by only update when a feature has been
> flagged.
OK, I didn't understand you meant patching Git itself for that. So it
makes sense to turn my toy patch into a real patch I guess. Any comment
on the capability name? I used dont-update-pr
On Mon, Aug 26, 2013 at 4:16 AM, Matthieu Moy
wrote:
> Matthieu Moy writes:
>
>> Junio C Hamano writes:
>>
>>> Matthieu Moy writes:
>>>
How would I do that? The update to the remote namespace is done by Git,
not by the remote-helper.
OK, I'm now convinced that my solution is
Matthieu Moy writes:
> Not updating was the default until 664059fb62 (i.e. until 1.8.4), so the
> default already changed once. I tend to agree with Felipe that doing the
> update by default makes sense.
OK. Thanks.
> git-remote-mediawiki is kind of a special case, as the remote side uses
> a
The current documentation mentions the private ref namespace, but does
not really explain why it can be useful.
Signed-off-by: Matthieu Moy
---
This small patch was sent inline during a previous conversation, but
did not really catch attention ;-).
Resending as a proper patch.
Documentation
ble to ask for a non-update without a fatal
> error on old Git versions, but this is not possible (hence, my fix is
> the "portable" one, that works on Git 1.8.4).
>
> But that's probably the best we can do now.
... and a patch implementing that would look like:
commit e438
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> How would I do that? The update to the remote namespace is done by Git,
>> not by the remote-helper.
>>
>> OK, I'm now convinced that my solution is the right one. The
>> alternatives are far more complex and I still fail to see the benefits.
>
Matthieu Moy writes:
> How would I do that? The update to the remote namespace is done by Git,
> not by the remote-helper.
>
> OK, I'm now convinced that my solution is the right one. The
> alternatives are far more complex and I still fail to see the benefits.
Sounds like a plan, even though it
Felipe Contreras writes:
> On Fri, Aug 23, 2013 at 3:25 AM, Matthieu Moy
> wrote:
>
>> This is assuming you follow the scheme
>>
>> git -> local repo for other vcs -> remote repo for other vcs
>>
>> which itself more or less assumes that the other VCS is a decentralized
>> VCS. I understand th
It is Private
I am George Daniels, a Banker and credit system programmer (HSBC bank).
I saw your email address while browsing through the bank D.T.C Screen in
my office yesterday so I decided to use this very chance to know you. I
believe we should use every opportunity to know each other better
good idea for hg or bzr remote helpers, but
> not applicable for git-remote-mediawiki.
A centralized repository is a subset of decentralized workflows.
> Back to my original problem: the point of dumb push is to make sure the
> next import will re-import the pushed revisions. if I use s
y better idea?
>>>
>>> Why not keep track of the revisions yourself? You can have file where
>>> you store which was the last revision that was fetched.
>>
>> I don't really understand the point of the "private namespace" anymore I
>> guess
sions yourself? You can have file where
>> you store which was the last revision that was fetched.
>
> I don't really understand the point of the "private namespace" anymore I
> guess. Why do we have both refs/remotes/$remote and
> refs/$foreign_vcs/$remote, if the
that was fetched.
I don't really understand the point of the "private namespace" anymore I
guess. Why do we have both refs/remotes/$remote and
refs/$foreign_vcs/$remote, if they are always kept in sync?
Keeping the last imported revision in a separate file would be possible,
but
run_git("update-ref -m \"Git-MediaWiki non-dumb push\"
>> refs/mediawiki/$remotename/master $reset_private_ref_to");
>> +}
>
> So reset-private-ref-to is recorded for a non-dumb push, but...
> ... it is set for dumb-push? I am confused.
Oops, I'm the one who
> The previous implementation was simply omitting the update to the private
> ref after a dumb push. This was broken by 664059fb62 (Felipe Contreras,
> Apr 17 2013, transport-helper: update remote helper namespace), which
> does an automatic update of the private ref (not just the
> r
simply omitting the update to the private
> ref after a dumb push. This was broken by 664059fb62 (Felipe Contreras,
> Apr 17 2013, transport-helper: update remote helper namespace), which
> does an automatic update of the private ref (not just the
> remote-tracking) on push.
>
> Th
Git-mediawiki's "dumb push" sends the local revisions to the remote wiki,
but does not update the local metadata to reflect the push (hence, the
next pull will have to re-import the exported revisions).
The previous implementation was simply omitting the update to the private
r
It is Private
I am George Daniels, a Banker and credit system programmer (HSBC bank).
I saw your email address while browsing through the bank D.T.C Screen in
my office yesterday so I decided to use this very chance to know you. I
believe we should use every opportunity to know each other better
Git-mediawiki's "dumb push" sends the local revisions to the remote wiki,
but does not update the local metadata to reflect the push (hence, the
next pull will have to re-import the exported revisions).
The previous implementation was simply omitting the update to the private
r
2013/8/9 Junio C Hamano :
> Elia Pinto writes:
>
>> Git use, as many project that use autoconf, private m4 macros.
>>
>> When not using automake, and just relying on autoconf, the macro
>> files are not picked up by default.
>>
>> A possibility, as gi
Elia Pinto writes:
> Git use, as many project that use autoconf, private m4 macros.
>
> When not using automake, and just relying on autoconf, the macro
> files are not picked up by default.
>
> A possibility, as git do today, is to put the private m4 macro
> in the confi
Git use, as many project that use autoconf, private m4 macros.
When not using automake, and just relying on autoconf, the macro
files are not picked up by default.
A possibility, as git do today, is to put the private m4 macro
in the configure.ac file, so they will copied over the final
On Sun, Mar 3, 2013 at 10:42 PM, Junio C Hamano wrote:
> I suspect that many people outside CGit circle may not know who this
> Jason
> That active contributor is Jason. The repository has also been moved
> to Jason's http://git.zx2c4.com/cgit/
> So, thanks, Jason and John for your efforts.
Hey f
"Jason A. Donenfeld" writes:
> Signed-off-by: Jason A. Donenfeld
I suspect that many people outside CGit circle may not know who this
Jason (who never appeared in git@vger.kernel.org) is, and are
wondering in what capacity he is sending a S-o-b for somebody else's
patch without explanation. An
On Mon, Mar 4, 2013 at 1:03 AM, John Keeping wrote:
> This reverts commit ba35480439d05b8f6cca50527072194fe3278bbb.
>
> CGit uses these symbols to output the correct HTML around graph
> elements. Making these symbols private means that CGit cannot be
> updated to use Git 1.8.0 or
Signed-off-by: Jason A. Donenfeld
On Sun, Mar 3, 2013 at 7:03 PM, John Keeping wrote:
> This reverts commit ba35480439d05b8f6cca50527072194fe3278bbb.
>
> CGit uses these symbols to output the correct HTML around graph
> elements. Making these symbols private means that CGit cannot
This reverts commit ba35480439d05b8f6cca50527072194fe3278bbb.
CGit uses these symbols to output the correct HTML around graph
elements. Making these symbols private means that CGit cannot be
updated to use Git 1.8.0 or newer, so let's not do that.
On top of the revert, also add comments so
1 - 100 of 133 matches
Mail list logo
