w repo
> > exists.
> > > I believe we have to use non-snapshot dependencies when creating an
> > > Accumulo release. Right? I have no issue with creating the repo now and
> > no
> > > issue with the name, since we can rename it.
> > >
> > > On W
Accumulo release. Right? I have no issue with creating the repo now and
> no
> > issue with the name, since we can rename it.
> >
> > On Wed, Sep 6, 2023 at 3:18 PM Keith Turner wrote:
> >
> > > I would like to create a new git repository named accumulo-access in
>
t.
> >
> > On Wed, Sep 6, 2023 at 3:18 PM Keith Turner wrote:
> >
> > > I would like to create a new git repository named accumulo-access in
> the
> > > ASF and want to know if anyone has thoughts about creating this repo.
> > This
> > > new repo wo
g the repo now and no
> issue with the name, since we can rename it.
>
> On Wed, Sep 6, 2023 at 3:18 PM Keith Turner wrote:
>
> > I would like to create a new git repository named accumulo-access in the
> > ASF and want to know if anyone has thoughts about creating this repo.
18 PM Keith Turner wrote:
> I would like to create a new git repository named accumulo-access in the
> ASF and want to know if anyone has thoughts about creating this repo. This
> new repo would be a home for the Accumulo access module being created in
> 3715[1].
>
> Once this repo
I would like to create a new git repository named accumulo-access in the
ASF and want to know if anyone has thoughts about creating this repo. This
new repo would be a home for the Accumulo access module being created in
3715[1].
Once this repository is created, then the following could happen
Hi Accumulo Devs!
Every once in a while, I share this link with people (I think I have
shared it on this list before as well), with helpful tips on writing
good git commit log messages. I'm sharing it again today because we
have had new contributors in the last year, some may find this u
[IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE
DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS]
Hello Apache projects,
I am writing to you because you may have git repositories on the
git-wip-us server, which is slated to be decommissioned in the coming
Hello Accumulo developers and users,
Accumulo has moved its source code repositories from git.apache.org /
git-wip-us.apache.org to gitbox.apache.org. If you were using the mirrors
at GitHub.com, then nothing has changed for you. Otherwise, you should
update your git remote to point to the new
Devs,
This is just a quick notice:
I just filed https://issues.apache.org/jira/browse/INFRA-13069
due to some of our recently created repos being configured with the
(annoying) defaults.
Fixing this will help address things like the comments on
https://issues.apache.org/jira/browse/ACCUMULO-4511
and
use it to reference.
The IDs are still there on each section, just the quick link to get
there is missing (so I have to look it up). Not sure if there is an
easy
way to get this with Jekyll (or if it'd just be something we have to
do
by hand).
Christopher wrote:
There's plenty
header (specifically on the release notes page) are missing.
>> >>>
>> >>> I liked those because it was easy to click the header to get a url and
>> >>> use it to reference.
>> >>>
>> >>> The IDs are still there on each sect
e because it was easy to click the header to get a url and
> >>> use it to reference.
> >>>
> >>> The IDs are still there on each section, just the quick link to get
> >>> there is missing (so I have to look it up). Not sure if there is an
> easy
&g
just the quick link to get
there is missing (so I have to look it up). Not sure if there is an easy
way to get this with Jekyll (or if it'd just be something we have to do
by hand).
Christopher wrote:
There's plenty of room for improvement to the new git/Jekyll site. For
instance, we can sta
27;d just be something we have to do
>> by hand).
>>
>> Christopher wrote:
>> > There's plenty of room for improvement to the new git/Jekyll site. For
>> > instance, we can start blogging there, so we have greater control over
>> the
>> > look
l (or if it'd just be something we have to do
> by hand).
>
> Christopher wrote:
> > There's plenty of room for improvement to the new git/Jekyll site. For
> > instance, we can start blogging there, so we have greater control over
> the
> > look and feel
quick link to get
there is missing (so I have to look it up). Not sure if there is an easy
way to get this with Jekyll (or if it'd just be something we have to do
by hand).
Christopher wrote:
There's plenty of room for improvement to the new git/Jekyll site. For
instance, we can star
There's plenty of room for improvement to the new git/Jekyll site. For
instance, we can start blogging there, so we have greater control over the
look and feel of our blog posts, and so any committer can blog without
needing to request an extra account. At some point, I think it'd
. The banner is
hidden on our canonical site.
On Mon, Mar 14, 2016 at 5:33 PM Christopher wrote:
> With the completion of INFRA-11437
> <https://issues.apache.org/jira/browse/INFRA-11437>, our site should now
> be building out of git. They wanted the branch to be called "asf-s
With the completion of INFRA-11437
<https://issues.apache.org/jira/browse/INFRA-11437>, our site should now be
building out of git. They wanted the branch to be called "asf-site", so I
renamed the one called "accumulo.apache.org". Shortly, I will be updating
the docs
Well, if I wasn't a git aficionado before, I'm well on my way. Using some
low-level git commands (making full use of StackOverflow[1]), I actually
put together a git post-commit hook to automatically regenerate and update
the accumulo.apache.org branch (assuming you have one checked o
nch called "
accumulo.apache.org"
3. Push the accumulo.apache.org branch
4. File INFRA ticket to switch our site to git using the
accumulo.apache.org
branch
On Fri, Mar 11, 2016 at 11:46 AM Billie Rinaldi
wrote:
Wow, that's looking great. Thanks, Christopher!
Billie
On Thu,
d "
> accumulo.apache.org"
> 3. Push the accumulo.apache.org branch
> 4. File INFRA ticket to switch our site to git using the
> accumulo.apache.org
> branch
>
>
> On Fri, Mar 11, 2016 at 11:46 AM Billie Rinaldi
> wrote:
>
> > Wow, that's looking
o switch our site to git using the accumulo.apache.org
branch
On Fri, Mar 11, 2016 at 11:46 AM Billie Rinaldi
wrote:
> Wow, that's looking great. Thanks, Christopher!
>
> Billie
>
> On Thu, Mar 10, 2016 at 10:38 PM, Christopher wrote:
>
> > Thanks Josh! I fixed a
wrote:
> > > Actually, I now have it all working (as far as I can tell) with
> > everything
> > > pretty much the same as it looks with CMS today. After people have
> taken
> > > the time to give it a glance, I'll push it to the ASF repo, and then
> push
&
gt; > the generated site to a separate branch. Then we can put in the INFRA
> > ticket to switch from svn to git.
> >
> > On Thu, Mar 10, 2016 at 6:42 PM Christopher wrote:
> >
> >> I'm working on converting our current site contents over to jekyll at
> >&
t;> Actually, I now have it all working (as far as I can tell) with everything
>> pretty much the same as it looks with CMS today. After people have taken
>> the time to give it a glance, I'll push it to the ASF repo, and then push
>> the generated site to a separate branch.
h
the generated site to a separate branch. Then we can put in the INFRA
ticket to switch from svn to git.
On Thu, Mar 10, 2016 at 6:42 PM Christopher wrote:
I'm working on converting our current site contents over to jekyll at
https://github.com/ctubbsii/accumulo/tree/gh-pages
(view at http:
icket to switch from svn to git.
On Thu, Mar 10, 2016 at 6:42 PM Christopher wrote:
> I'm working on converting our current site contents over to jekyll at
> https://github.com/ctubbsii/accumulo/tree/gh-pages
> (view at http://ctubbsii.github.io/accumulo)
>
> Yes, it's
Github (both
> apache/accumulo
> >>>>> github account and other forks).
> >>>>>
> >>>>> Christopher had said that no one seemed to object in comdev@ when he
> >>>>> talked about this a while back. I wanted to make sure everyon
point, only
suggesting that we give it some thought and maybe ask someone who is
more knowledgable (Shane from trademarks?) before moving forward. The
worst case I envision is that we find some way to "gimp" the
github-rendered site (redirect back to the canonical
accumulo.apache.org
or simil
nonical host of the Apache Drill project). I'm
> >>> not actively stating that I think it's an issue at this point, only
> >>> suggesting that we give it some thought and maybe ask someone who is
> >>> more knowledgable (Shane from trademarks?) before moving f
owledgable (Shane from trademarks?) before moving forward. The
worst case I envision is that we find some way to "gimp" the
github-rendered site (redirect back to the canonical accumulo.apache.org
or similar).
Christopher wrote:
I got some information back from INFRA about how the gi
orward. The
> > worst case I envision is that we find some way to "gimp" the
> > github-rendered site (redirect back to the canonical accumulo.apache.org
> > or similar).
> >
> > Christopher wrote:
> >> I got some information back from INFRA about how the git-ba
to "gimp" the
github-rendered site (redirect back to the canonical accumulo.apache.org
or similar).
Christopher wrote:
I got some information back from INFRA about how the git-based sites
work.
It's just plain old static hosting of a git branch. So, whatever we'd put
in a
ttp://www.apache.org/foundation/marks/
http://www.apache.org/foundation/marks/domains.html
>
>
> Christopher wrote:
>
>> I got some information back from INFRA about how the git-based sites work.
>> It's just plain old static hosting of a git branch. So, whatever we'd put
>
rg
or similar).
Christopher wrote:
I got some information back from INFRA about how the git-based sites work.
It's just plain old static hosting of a git branch. So, whatever we'd put
in a specified branch would show up directly on the site, no rendering or
generation. This would compl
+1 sounds great!
On Mon, Mar 7, 2016 at 5:09 PM, Christopher wrote:
> I got some information back from INFRA about how the git-based sites work.
> It's just plain old static hosting of a git branch. So, whatever we'd put
> in a specified branch would show up directly on the
I got some information back from INFRA about how the git-based sites work.
It's just plain old static hosting of a git branch. So, whatever we'd put
in a specified branch would show up directly on the site, no rendering or
generation. This would completely bypass CMS and buildbot stag
Thanks for taking the time to clean these up!
Christopher wrote:
Not much change. After doing 'git gc --aggressive --prune=now' on a 'git
clone --mirror', the repo size was 33M before the removal of these refs,
and 27M after. Since they were mostly pointing to existing blob
Not much change. After doing 'git gc --aggressive --prune=now' on a 'git
clone --mirror', the repo size was 33M before the removal of these refs,
and 27M after. Since they were mostly pointing to existing blobs, I
wouldn't expect it to have dropped much. I'm actually
Any stats on what the repo size is after removing the refs and doing
something like `git gc`?
On Fri, Mar 4, 2016 at 4:25 PM, Christopher wrote:
> I was able to deleted 135 duplicate refs of the kind I described. Only one
> resulted in a new branch being created (ACCUMULO-722). We pr
s an inactive branch.
Also note that the ACCUMULO-722 branch is not rooted on any other branches
in our git repo. It was essentially just a sandbox in svn where Eric had
been working.
On Wed, Mar 2, 2016 at 6:14 PM Christopher wrote:
> (tl;dr version: I'm going to clean up refs/remotes
(tl;dr version: I'm going to clean up refs/remotes/** in git, which
contains duplicate history and messes with 'git clone --mirror'; these are
refs which are neither branches nor tags and leftover from git-svn)
So, when we switched from svn to git, there were a lot of leftover r
This was a branch Keith had previously unintentionally pushed to the wrong
repo. Looks like it can be deleted now.
On Mon, Jan 11, 2016 at 9:14 PM wrote:
> Repository: accumulo
> Updated Branches:
> refs/heads/ACCUMULO-2883 [deleted] 1ae1b34f3
>
But what actual value do these JIRAs add? What is the benefit that the git
log message doesn't provide?
On Thu, Jan 7, 2016, 09:54 Josh Elser wrote:
> I think I disagree that they are a lot of work or a big distraction.
>
> The amount of work behind a trivial change (in terms of
I think I disagree that they are a lot of work or a big distraction.
The amount of work behind a trivial change (in terms of the tool: git)
is no different (you commit to all active branches and maybe fix merge
conflicts).
Personally, I find little nit-picky things good to just piggy-back on
e are often multiple open for the same scope, and they offer
nothing that grepping the logs wouldn't give.
Rather than people find ways around the system, I think it's better if we
just admit that some commits are too trivial to track in JIRA (in addition
to git... where they are alread
with a different patch set"
> posing some great roadblock to us?
>
> Not to nitpick too much, but I think the significance of git in this
> discussion is minimal-- the same problem could be had w/ any VCS.
>
> On Wed, Jan 6, 2016 at 3:28 PM, Christopher wrote:
>
> >
patch set"
posing some great roadblock to us?
Not to nitpick too much, but I think the significance of git in this
discussion is minimal-- the same problem could be had w/ any VCS.
On Wed, Jan 6, 2016 at 3:28 PM, Christopher wrote:
> Accumulo Devs,
>
> We typically create a JIRA for
Accumulo Devs,
We typically create a JIRA for every change, and then explicitly reference
that JIRA in the git commit log. Sometimes, this seems like a lot of work
(or, at the very least, a big distraction) for *really* trivial changes[1].
My question(s):
What are the pros and cons of being
(b83f88caf), but if others are satisfied, I'm fine
with it how it is now.
Just please try to be careful from now on, and avoid force pushing. If
something was pushed by mistake, please push a reverse commit created
with 'git revert '.
--
Christopher L Tubbs II
http://gravatar.com/
This was an oops in two parts. I was trying to make a push a small change to
the docs client section.
My change was refs/heads/1.6 967100dda -> b83f88caf but I mistakenly also ended
up committing / pushing changes associated with:
Merge branch '1.6' of https://git-wip-us.apache.
help, please ask.
Thanks.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
-- Forwarded message --
From:
Date: Sun, Jul 26, 2015 at 12:29 AM
Subject: Git Push Summary
To: comm...@accumulo.apache.org
Repository: accumulo
Updated Branches:
refs/heads/1.6 b83f88caf -> 967100dda (forced update)
On Tue, Feb 10, 2015 at 2:25 PM, wrote:
> Repository: accumulo
> Updated Branches:
> refs/heads/1.6 dc471efee -> ac44627eb
>
>
> ACCUMULO-3572 demote fileSize print to trace
>
>
> Project: http://git-wip-us.apache.org/repos/asf/accumulo/repo
> Commit: http:
issue when it is completed, even if the parent issue isn't yet
complete. (unless somebody has a better suggestion)
Doing these two things will help ensure that our CHANGES / release notes
actually reflect the work which was done in a tagged release and prevent
discrepancies between JIRA a
On Tue, Oct 7, 2014 at 9:49 AM, William Slacum <
wilhelm.von.cl...@accumulo.net> wrote:
>
> I think Christopher's real issue (re: #2) is that it's ambiguous what
> bleeding-edge/trunk development should look like, because we don't have a
> defined goal. I proposed getting rid of master, or treatin
> > While we're a big project, I think we might be able to benefit from a
> > review-then-commit process. It could allow us to review any patch to
> > master, and if we determine it is relevant in historical branches, we
> > commit it to the historical branch and then
story.
>
We decided to try RTC on Fluo. I love it. We worked out a process using
git and GH infrastructure that minimizes friction/overhead. We are still
refining the process and change it whenever something seems inefficient or
isn't working well. We are small team so we can be very agi
On Tue, Oct 7, 2014 at 9:50 AM, Sean Busbey wrote:
> On Oct 7, 2014 5:25 AM, "William Slacum"
> wrote:
> >
> > #1 would be nice. I would discourage the cherry-pick-back-from-master
> model
> > because it completely disregards git's history model and makes auditing
> > changes nearly impossible b
release manager can determine what
> does or does not get included
>
> 3) a git history that makes it easy for me to tell what jiras impact a
> given release tag
>
> One way to achieve these goals is to adopt a commit-to-master and
> cherry-pick approach.
>
> * Master would
On Oct 7, 2014 5:25 AM, "William Slacum"
wrote:
>
> #1 would be nice. I would discourage the cherry-pick-back-from-master
model
> because it completely disregards git's history model and makes auditing
> changes nearly impossible because for N patches, the same change exists N
> times under differ
tory.
>>
>>
>>
>> On Tue, Oct 7, 2014 at 1:12 AM, Sean Busbey wrote:
>>
>>> What if we start with what we want and work from there, instead of
>>> starting
>>> from our current model.
>>>
>>> I would really like:
>>
gt; I would really like:
>>
>> 1) A *single* place where new contributors can base patches
>>
>> 2) Stable planned release lines where a release manager can determine what
>> does or does not get included
>>
>> 3) a git history that makes it easy for me to
nt model.
>
> I would really like:
>
> 1) A *single* place where new contributors can base patches
>
> 2) Stable planned release lines where a release manager can determine what
> does or does not get included
>
> 3) a git history that makes it easy for me to tell what j
What if we start with what we want and work from there, instead of starting
from our current model.
I would really like:
1) A *single* place where new contributors can base patches
2) Stable planned release lines where a release manager can determine what
does or does not get included
3) a git
new
> >> contributor would expect to fork to create a patch. That's hard to do if
> >> the goalpost is moving a lot, and it makes feature merges more
> >> complicated,
> >> since contributors have to rebase or merge themselves in order to
> create a
&
>> since contributors have to rebase or merge themselves in order to create a
>> patch that merges cleanly. Having a stable master makes it very easy to
>> contribute to the most recent release.
>>
>
> No, I don't really care for a stable-only master (I think I diverge from
> the git-flow model in that regard). I like master to just be a
> "commits-go-here" area more than anything.
>
merges cleanly. Having a stable master makes it very easy to
contribute to the most recent release.
No, I don't really care for a stable-only master (I think I diverge from
the git-flow model in that regard). I like master to just be a
"commits-go-here" area more than anything.
oalposts. And the more explicit name is a benefit,
I'd argue.
> Most of the theory behind what Josh wanted comes from this blog post:
> http://nvie.com/posts/a-successful-git-branching-model/ One of the
> disconnects between our branching strategy and the one it describes is t
ump in the branch. We don't
have to be stuck with it.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
> --
> Sean
> On Oct 6, 2014 6:18 PM, "Christopher" wrote:
>
> > Okay, so when we first switched to git, Josh argued that the master
> branch
> > shou
name.
Most of the theory behind what Josh wanted comes from this blog post:
http://nvie.com/posts/a-successful-git-branching-model/ One of the
disconnects between our branching strategy and the one it describes is that
it doesn't really account for long term support branches. I don't th
18 PM, "Christopher" wrote:
> Okay, so when we first switched to git, Josh argued that the master branch
> should be pristine... it should reflect the most recently released version.
> We have not been doing that. Instead, we've been treating it as the main
> development b
Okay, so when we first switched to git, Josh argued that the master branch
should be pristine... it should reflect the most recently released version.
We have not been doing that. Instead, we've been treating it as the main
development branch, following SVN conventions and treating it like
On Mon, Sep 29, 2014 at 9:36 AM, wrote:
> Repository: accumulo
> Updated Branches:
> refs/heads/master 159d1b99d -> 1dfe826ce
>
>
> ACCUMULO-2480 make the tserver give up and die if openning the WAL
> experiences 5 errors in 10 seconds
>
>
> Project: http:
http://git-wip-us.apache.org/repos/asf/accumulo/blob/72156b82/server/tserver/src/main/java/org/apache/accumulo/tserver/log/TabletServerLogger.java
--
diff --git
a/server/tserver/src/main/java/org/apache/accumulo/tserver/log
us;action=diff;uri=http://accumulo.apache.org/git.mdtext
>>
>> Alex Moundalexis
>>
>> Index: trunk/content/git.mdtext
>> ===
>> --- trunk/content/git.mdtext(revision 1581605)
>> +++ trunk/
581605)
> +++ trunk/content/git.mdtext(working copy)
> @@ -143,6 +143,24 @@
>
> `git commit -av`
>
> + Please include the ticket number at the beginning of the log message,
> and
> + in the first line, as it's easier to parse quickly. For example:
> +
&g
)
+++ trunk/content/git.mdtext(working copy)
@@ -143,6 +143,24 @@
`git commit -av`
+ Please include the ticket number at the beginning of the log message, and
+ in the first line, as it's easier to parse quickly. For example:
+
+`ACCUMULO-2428 throw exception when rename
===
--- trunk/content/git.mdtext(revision 1579871)
+++ trunk/content/git.mdtext(working copy)
@@ -115,7 +115,7 @@
Use the following steps, original derived from Apache Kafka's [simple
contributor
-workflow](https://cwiki.apache.org/confluence/display/KAFKA/Git+Workflow#GitWor
)
+++ trunk/content/git.mdtext(working copy)
@@ -115,7 +115,7 @@
Use the following steps, original derived from Apache Kafka's [simple
contributor
-workflow](https://cwiki.apache.org/confluence/display/KAFKA/Git+Workflow#GitWorkflow-Simplecontributorworkflow).
+workflow](https://cwiki.apach
The hash points indirectly at the commit because it carries signature
information.
On Mar 4, 2014 12:00 AM, "Christopher" wrote:
> Yeah, I guess I was just confused, because I expected the hash
> provided in the message to point to the HEAD commit in the tag, not
> something specific to the tag's
Yeah, I guess I was just confused, because I expected the hash
provided in the message to point to the HEAD commit in the tag, not
something specific to the tag's own blob.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Mon, Mar 3, 2014 at 8:04 PM, John Vines wrote:
> Deleting the rc
Deleting the rc tag?
On Mon, Mar 3, 2014 at 7:34 PM, Christopher wrote:
> Nevermind and disregard. I'm mistaken. We voted on 3478f71a as
> 1.5.1-rc3... this tag is correct.
>
> However, I am confused about the previous push delete:
> "Updated Tags: refs/tags/1.5.1-rc3 [deleted] c485b41f7"
>
>
Nevermind and disregard. I'm mistaken. We voted on 3478f71a as
1.5.1-rc3... this tag is correct.
However, I am confused about the previous push delete:
"Updated Tags: refs/tags/1.5.1-rc3 [deleted] c485b41f7"
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Mon, Mar 3, 2014 at 7:27 PM,
This does not look correct. The 1.5.1 tag should have been the GPG
signed one that Josh was going to create from the 1.5.1-rc3
(c485b41f7). This is a different SHA1 entirely.
--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Mon, Mar 3, 2014 at 2:42 PM, wrote:
> Repository: accumulo
>
> emails
>>>>> included the branch and repo (e.g. .
>>>>> accumulo-wikisearch.git refs/heads/1.4.5-SNAPSHOT [created]
>>>>> e15859054)
>>>>>
>>>>
>>>> An INFRA ticket may be able to help us here. I seem to remember there
>>>> being a set of replacement strings (ala printf %s, %d, etc) that were
>>>> available to customize things like the email subject. I can't find that
>>>> list at the moment, though.
>>>
>>>
>>>
>>> Then I find it 5 seconds later:
>>> https://git-wip-us.apache.org/docs/commit-emails.html
>>>
>>> %repo looks like it would be what you're asking for. I'd be fine with
>>> that,
>>> too.
can't find that
list at the moment, though.
Then I find it 5 seconds later:
https://git-wip-us.apache.org/docs/commit-emails.html
%repo looks like it would be what you're asking for. I'd be fine with that,
too.
help us here. I seem to remember there
>> being a set of replacement strings (ala printf %s, %d, etc) that were
>> available to customize things like the email subject. I can't find that
>> list at the moment, though.
>
>
> Then I find it 5 seconds later:
> https://git-wip-us.apache.org/docs/commit-emails.html
>
> %repo looks like it would be what you're asking for. I'd be fine with that,
> too.
t strings (ala printf %s, %d, etc) that were
available to customize things like the email subject. I can't find that
list at the moment, though.
Then I find it 5 seconds later:
https://git-wip-us.apache.org/docs/commit-emails.html
%repo looks like it would be what you're asking for. I&#
On 2/6/14, 11:51 AM, Keith Turner wrote:
>Updated Branches:
> refs/heads/1.4.5-SNAPSHOT [created] e15859054
>
In case anyone else is confused about these 50 emails like I was, these
were pushed to accumulo-wikisearch.git and not accumulo.git. I emailed
Bill and he helped me sort myself out
yself outIt would be nice if these emails
included the branch and repo (e.g. .
accumulo-wikisearch.git refs/heads/1.4.5-SNAPSHOT [created] e15859054)
>
>
> ACCUMULO-354 added boolean instead of null to detect presence of next value
>
> git-svn-id:
> https://svn.apache.org/r
Regarding git workflows,
http://cdn.memegenerator.net/instances/500x/43613593.jpg
On Fri, Dec 6, 2013 at 6:28 PM, Josh Elser wrote:
> I think Bill (ujustgotbi...@apache.org) is the component lead. He'd
> probably be a good start.
>
> But in all honesty, I don't kno
I'm getting started on making sure we have a wikisearch example that can
run on Accumulo 1.4.x versions[1].
I was wondering who the likely maintainers for the wikisearch example are
and if they intend to follow the same git workflow that the main project
uses[2]?
[1]: https://issues.apache
Hi!
I'm getting started on making sure we have a wikisearch example that can
run on Accumulo 1.4.x versions[1].
I was wondering who the likely maintainers for the wikisearch example are
and if they intend to follow the same git workflow that the main project
uses[2]?
[1]:
Hi Terry!
1. The short answer is no.
the git commands present in our guide tell you to use "git commit -a",
which is a short cut to saying "include all changed files in this commit."
Its use is frowned upon in most of the coding communities I've been in,
because it
Greetings folks,
I'm working on ACCUMULO-1901 but am a newbie with git and want to ensure I
do my check-in and patch correctly the first time.
My questions are:
1. 'git help commit' says "even modified files must be 'added'" but the
Accumulo Contributor inst
e any
git tricks for redoing conflict resolution.
On 11/16/2013 11:26 AM, Keith Turner wrote:
On Sat, Nov 16, 2013 at 12:36 AM, Josh Elser
wrote:
Obviously I saw the conflict as I had thought I had correctly resolved
it.
I guess not.
I was not sure about that. I was not sure how you
I know what needs to be done. I'll do it.
Should this just be a plain old commit in 1.5? Not sure if there are any
git tricks for redoing conflict resolution.
>
>
> On 11/16/2013 11:26 AM, Keith Turner wrote:
>
>> On Sat, Nov 16, 2013 at 12:36 AM, Josh Elser
>> w
:
Obviously I saw the conflict as I had thought I had correctly resolved it.
I guess not.
I was not sure about that. I was not sure how you were doing things. It
seems like the conflict was resolved in such a way that all 1.5 changes
were taken, I was wondering if this was done w/ a git command
1 - 100 of 256 matches
Mail list logo
